[lkml]   [2002]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectPossible breakthrough in the CML2 logjam?
    Jeff Garzik <>:
    > Ideally in the future I can add and update a driver's makefile and
    > configuration information by patching drivers/net/netdriver.c and
    > drivers/net/netdriver.conf, and touch absolutely no other files.

    That's very much the direction I'd like to go in, Jeff. I'm
    surprised and delighted to hear you say this. You're actually
    anticipating my plans for six months down the road. Maybe we
    have some common ground here.

    One of the objectives of the CML2 language design is to make it
    amenable to being generated by a metadata analyzer. I mean some very
    specific things by this.

    One important property which CML2 declarations have that CML1 syntax
    does not is that (a) they're not order-dependent, and (b) they have
    strong locality (that is, the syntactic context of a single
    declaration holds all the semantic information -- you don't have to go
    monkey-climbing up a bunch of enclosing syntax to parse it, or
    *generate* a bunch of enclosing syntax to express it).

    These properties tremendously simplify generating a rulebase from
    (so far hypothetical) analysis tools. My first step would be to
    automatically generate CML2 bus-guard information from annotations
    in the driver sources. Once I write a tool that can do that, I can whack
    about 25% of the rulebase, including most of the parts that are a
    maintainance headache.

    My longer-term plan is to whittle away at the manually-maintained
    rulebase until nothing but menu structure and a handful of cross-
    directory requirements are left. Everything else should be generated
    by a program that turns source-code metadata into stereotyped CML2

    Even a lot of the menu structure might be generatable, requiring it
    to be specified only in exception cases where as a matter of UI design
    choice you don't want to track the code hierarchy.

    This has been part of my long-term plan since about eighteen months
    ago. It's had a major, *major* impact on the language design. In
    particular it's one of the reasons visibility and implication
    can be declared separately from the menu structure.

    If you go back and look at the language design from this point of view,
    I think many things you might not have seen the point of before will
    become clearer.

    Note well two points:

    1. This can't practicably be done in CML1. CML1 markup has crappy
    locality; the metadata analyzer would have to carry around way too
    much state about other symbols in order to generate the markup for any
    given one.

    2. This design basically demands a single-apex tree. Otherwise I don't
    think you can get the consistency-checking right -- I haven't been
    able to invent a method to do it, anyway.

    So if you want this, please start backing CML2 and contributing in a
    positive way. I know how to get where you want to go. CML2 is
    specifically intentionally designed to make it possible, and I have the
    will to follow through.

    But for these good things to happen, CML2 *got to go in*. I cannot both
    continue the enormous effort of maintaining a parallel rulebase
    and move the ball forward towards automatic rule generation from metadata
    and other good things. That's what I want to be working on.
    <a href="">Eric S. Raymond</a>
    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:24    [W:0.027 / U:20.820 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site