[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CML2 design philosophy heads-up
    Date said:
    > I'll take that as a vote for (b), to handle even perverse
    > configurations even if it means adding a lot of complexity to the
    > ruleset.

    As long as the ruleset is sufficient to represent the desired parts of the
    original behaviour of CML1, that should be fine.

    Which means that it must be possible to individually select drivers which
    aren't standard for your board. The dependencies in CML1 are (supposed to
    be) absolute - the 'advisory' dependencies you're adding are arguably a
    useful feature, but please don't make it possible to confuse the two, and
    please do make sure it's possible to disable the latter form.

    I'm one of the people who Jes has heard saying both 'I don't care' and
    'NO!'. The latter on the occasions when it seems you're going to be
    reducing the usablility of the existing system.

    I am happiest when my interaction with the config system consists only of
    'cvs {commit,update} .config' 'pico .config' and 'make oldconfig'. I don't
    configure kernels for new boards very often - but on the occasions I do,
    it's often embedded boards based on a reference design, with irrelevant
    hardware omitted and some new stuff added in.

    Having the capability to fix up CVS conflicts in 'make oldconfig' would be
    a random feature creep that I _would_ approve of :)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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