[lkml]   [2001]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CML2 1.0.0 release announcement
    Jeff Garzik <>:
    > wrote:
    > > But, as a separate issue, the CML2 design *could* be reworked to support
    > > a multiple-apex tree, if there were any advantage to doing so. I don't
    > > see one. Do you?
    > Yes, because the current system is directed not by a central file, but
    > by an architecture-specific Compartmentalized
    > files are easy to include and even easier to exclude selectively. It's
    > pretty pointless for S/390 arch to parse a ton of driver config entries
    > it will never present to the user; that wastes memory and slows down the
    > configuration system.

    The low-level answer is that the configurator doesn't pay the
    parse-time cost; the CML2 compiler does all that and presents the
    configurator with a rulebase object that is not large enough for the
    incremental I/O or memory cost of the "useless" information to be
    significant. (I'm not handwaving here, I've actually profiled this;
    the rulebase object for 2.4.3 is only 342K on disk and less than that
    in core.)

    BTW, CML2 only has a "central file" in a rather trivial sense. Here's
    what the code to include the port-specific rules looks like:

    source "arch/i386/rules.cml"
    source "arch/alpha/rules.cml"
    source "arch/sparc/rules.cml"
    source "arch/mips/rules.cml"
    source "arch/ppc/rules.cml"
    source "arch/m68k/rules.cml"
    source "arch/arm/rules.cml"
    source "arch/sh/rules.cml"
    source "arch/ia64/rules.cml"
    source "arch/parisc/rules.cml"
    source "arch/s390/rules.cml"
    source "arch/cris/rules.cml"

    The real issue isn't that they're "centralized", it's that they're
    siblings under a top-level architecture menu (which most users won't
    see because normal invocations of the configurator supply that answer
    from the command line, just as in CML1). Which brings me neatly
    to my next point...

    The higher-level answer is that you're confusing an implementation
    issue with a design issue. Beware of such premature optimization, for
    as the hierophant Knuth hath revealed unto us, it is the root of all
    evil. To persuade me to go back to a multiple-apex tree you'd have to
    show that there is a *design* or complexity-control advantage to
    compartmentalizing the configuration information in that way. Maybe
    there is one, but nobody's shown it to me yet.

    (In truth I don't dismiss implementation concerns quite as cavalierly
    as it might sound from the above. But buying a linear speedup wouldn't
    be good enough to make me change the design. A quadratic speedup might
    be, but none of CML2's algorithms are quadratic in the number of symbols
    in the rulebase.)
    <a href="">Eric S. Raymond</a>

    The men and women who founded our country knew, by experience, that there
    are times when the free person's answer to oppressive government has to be
    delivered with a bullet. Thus, the right to bear arms is not just *a*
    freedom; it's the mother of all freedoms. Don't let them disarm you!
    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 13:25    [W:0.026 / U:67.144 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site