lkml.org 
[lkml]   [2001]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: CML2 1.3.1, aka "I stick my neck out a mile..."
    John Stoffel <stoffel@casc.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
    problem.

    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
    especially relevant.

    > 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 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/

    \
     
     \ /
      Last update: 2005-03-22 12:52    [W:3.677 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site