John Stoffel <email@example.com>:
> It should then highlight *all* of the potential problem config
> setting(s) and let the user deal. But they should never be forced to
> hand edit their config file because a dependency is broken somewhere.
> CML2 should enforce the *writing* of compliant files, but should deal
> gracefully with non-compliant ones. Within reason of course.
The "within reason" is the problem. It's very easy to construct
simple cases of invalid configs that blow the number of `tainted'
symbols up much larger than the number of violated constraints. An
interface of the kind you suggest would deluge the user with possible
things to be corrected without actually revealing the nature of the
Besides, right now the configurator has a simple invariant. It will
only accept consistent configurations and it will only write
consistent configurations -- in fact, your configuration is guaranteed
correct after ever attempt to change a symbol with the configurator
itself. I'm very, very reluctant to do anything that will go near
breaking that invariant.
I believe the the right fix is to go through the one-time transition
necessary to be in a world where inconsistent configurations never get
written, rather than to be overly accomodating to yesterday's bugs.
> Eric> USB and SCSI are both enabled/disabled in the system buses menu.
> Eric> The apparent confusion
> Then they should be pushed down a level to be under those buses. They
> don't belong on the top level.
That doesn't work either. See the "Good style in rulebase design"
section in the CML2 paper for discussion. The last paragraph is
> More correctly, *any* configuration setting on an upper level should
> not depend on a lower level setting.
Sorry, that's dreadfully bad advice and is not going to happen. If I did
as you suggest, I'd be throwing out the ability to do consistency
checks and deduce side effects.
-- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 30 2001 - 21:00:25 EST