Jeff Garzik <jgarzik@mandrakesoft.com>:
> 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
markup.
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="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> - 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/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:11 EST