Messages in this thread |  | | From | John Stoffel <> | Date | Thu, 3 May 2001 14:13:07 -0400 | Subject | Re: Why recovering from broken configs is too hard |
| |
Eric> David Mansfield <lkml@dm.ultramaster.com>: >> If so, given the above ruleset involving symbols A, B and C, and given >> that such a ruleset is violated for some reason (you don't even care >> why), use the following approach: >> >> set C to 'n' -> are we ok? >> set B to 'n' -> are we ok? >> set A to 'n' -> are we ok? >> >> Inform the user of each change. In a massively broken configuration you >> could end up with a lot of stuff set to 'n' ultimately, but I think that >> this generally would just end up shutting off troublesome configuration >> settings, and requiring that the user then reset them manually.
Eric> Actually this is the best idea I've seen yet, because the single Eric> "known-good" configuration is almost all n values.
Darnit! Someone else beat me to this idea, though David did a much better job of describing the solution here. *grin*
What Eric has been arguing about with the 3^n problem of finding the correct constrained state is interesting (and mathematically over my head), I wanted to point out that our real world setting here has some easy to do fixes, but just turning stuff off (and telling the user you did so!) and then letting the user turn stuff back on.
Keith Owens also had a good comment on how to deal with an broken config.
A) go interactive! Don't dump the user to vi, just put them in and tell them to fix their constraints themselves. This was my original beef with CML2, it didn't continue interactive so I could fix the problem, I had to hack it by hand.
For the non-interactive, setting stuff to 'n' should prune away problem states by the *ton* drastically simplifying the set of constraints to be satisfied.
Thanks for everyone chipping in here, it's been a interesting discussion to follow, and I'm hoping to see that we can prune back the problem easily enough to handle most cases of broken configs by working towards the known good config of mostly 'n' answers.
John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |