Re: Why recovering from broken configs is too hard

[John Stoffel <stoffel@casc.com>]

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