A recent thread on the Linux kernel mailing list (lkml) started off by generally bashing Eric S Raymond (ESR). Sifting through the many insults and round trip name calling, though, there was some constructive debating.

The thread was initiated by Jeff Garzik, in response to a message on the kbuild developer's list. The message, from ESR, is a four-point list of suggestions, asking members of the kbuild developer's list to speak with Dirk Hohndel about CML2 and kbuild-2.5, who in turn was to speak with Linus. That thread continues constructively, discussing the pro's and con's of both new systems.

With Jeff's email, the thread was essentially moved to the lkml, an often less-than-friendly environment. Involved in the ensuing debates were many kernel hacker notables, including Alan Cox, Dave Jones, Robert Love, Alexander Viro, Rob Landley, and of course Jeff Garzik and Eric S Raymond. Many of the arguments on both sides seemed a bit ridiculous and melodramatic, in my humble opinion (more personality conflicts than anything), but the ultimate issue is interesting and worth talking about: CML2 is a complete re-write of CML1, so different that it doesn't even attempt to be backward compatible. In the end, is CML1 broken enough and is CML2 superior enough to justify the effort required to make the upgrade?

Before diving into the debate, perhaps a little background is in order. CML1 is the original Configuration Menu Language, currently used to configure the Linux Kernel. CML2 was written by ESR to address short comings in CML1, and ultimately to make kernel configuration a simpler process. (So much so, that people complain of the 'Aunt Tillie Factor' - i.e.: why do we care if Aunt Tillie can compile a kernel?)

One of the "problems" people keep bringing up in regards to CML2 is its reliance on Python 2. However, some time ago Linus made it clear that this was in and of itself not an issue. As per the March 30, 2001 Kernel Summit, following a presentation by Keith Owens and ESR, Linus agreed to include CML2, deciding that the switch, when occurring, would be sudden - simply dropping CML1 and replacing it with CML2. However, much arguing has continued since then, and CML2's inclusion in the 2.5 kernel still seems to be up in the air.

If CML2 is ever to be included in 2.5, it sounds like most feel it needs to be broken up into a series of smaller patches. It would then be possible for the development community to choose which they wanted and which they didn't. (As it stands - it's all or nothing.) And, as noted by Alan Cox, CML1 can be fixed. Many agree that CML2 offers some nice improvements, but that it also brings in far too many changes. Many of which are completely unnecessary, such as user interface changes.

You can find much information about CML2 on Eric's CML2 Resources Page. On that page, there is information on migrating from CML1 to CML2, an informative white paper, a reference guide, and much more.

---

The thread started off with a round of insults:

From: Jeff Garzik
Subject: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 11:55:54 EST

Ladies and gentlemen,

I would find this pathetic, if it didn't make me so mad.
Making an end run around the system, are we, Eric?

Small wonder the message below didn't make it to linux-kernel:
suggestions would have been made that CML2 is DOA.

ESR's message to the kbuild list:
        http://marc.theaimsgroup.com/?l=kbuild-devel&m=101373619625183&w=2
The rest of the thread:
        http://marc.theaimsgroup.com/?t=101373623000001&r=1&w=2

For an open source "guru", Eric, you sure seem to like to turn to
cronyism and secret meetings when the going gets tough.

        Jeff

-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com



From: Rik van Riel
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 12:02:21 EST

This makes me wonder whether Eric works in a cathedral
or in an ivory tower ...

Rik

-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document



From: Alexander Viro
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 12:35:03 EST

Judging by usual Eric's intellectual erm... output the word you are looking
for is "outhouse".

Eric was quick to reply to many of these comments:

From: Eric S. Raymond (esr@thyrsus.com)
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 11:51:47 EST

Jeff Garzik:
> I would find this pathetic, if it didn't make me so mad.
> Making an end run around the system, are we, Eric?

No. I'm doing what Dirk Hohndel recommended I do during a phone call
that happened at his initiative, last Friday morning.

What "system" would you be referring to, anyway, Jeff? Is there some
reason a respected open-source developer like Dirk who has concerns
should not have a conversation with Linus to address problems he thinks
are significant? Is there some reason I should not have asked the kbuild
team members to give him appropriate background?

I don't understand what is upsetting you. Is there some rule that all
conversations with Linus must go through Jeff Garzik? If so, I was never
informed of it.

-- 
		Eric S. Raymond



From: Dave Jones
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 12:25:07 EST
On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:

> I don't understand what is upsetting you. Is there some rule that all
> conversations with Linus must go through Jeff Garzik? If so, I was never
> informed of it.

 No, but at the least keeping Linux-Kernel in the loop would be
 considered not just nice, but a somewhat more courteous method
 than 'sending someone around to go see Linus' when your pet
 project isn't getting the acceptance you hoped for.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs



From: Eric S. Raymond
Date: Fri Feb 15 2002 - 14:01:01 EST

No sending around is involved. Dirk approached me, not the other
way around.

---

From: Larry McVoy
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 12:25:56 EST

On Fri, Feb 15, 2002 at 11:51:47AM -0500, Eric S. Raymond wrote:
> Jeff Garzik:
> > I would find this pathetic, if it didn't make me so mad.
> > Making an end run around the system, are we, Eric?
>
> What "system" would you be referring to, anyway, Jeff? Is there some
> reason a respected open-source developer like Dirk who has concerns
> should not have a conversation with Linus to address problems he thinks
> are significant? Is there some reason I should not have asked the kbuild
> team members to give him appropriate background?

Yeah, there is. The point of *open* source is that it is *open*, Eric.
Jeff, if I understand him correctly, is making the point that if a
system can't stand up to public scrutiny, trying to get it in by private
campaigning is lame, not the open source way, and a little bit sleazy.

The open source development model depends on peer review, you might go
back and read some of your many essays on the topic. Don't you take
commercial companies to task for doing exactly what you are doing?
Your actions are confusing, do your writings apply to other people but
not to you? If there is some misunderstanding about your actions,
please clear it up. If not, practice what you preach.

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm



From: Eric S. Raymond
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 12:13:15 EST

So what "private campaigning" is going on here, exactly?

Dirk approached me because he was concerned that politics and poor
communication might be getting in the way of some valuable work. He
asked me to have the kbuild team fill him in on the background, and I
relayed that request. The kbuild team's discussion with Dirk is
taking place on a public mailing list.

I'm bewildered. What's the problem here?

---

Later in the thread, Alan Cox and ESR had a debate. Alan seems to be of the mind that CML1 can be fixed, so there is no need to migrate to CML2.

From: Alan Cox
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 16:34:52 EST

> Sure CML2 fixes some bits that are not easily fixed in CML1,
> but I wonder sometimes how much of it is/was fixable.

Pretty much all of it. I wrote a proof of concept parser that can deduce
the set of rules that must be enforced and what must be changed when you
hit an option



From: Eric S. Raymond
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 15:59:46 EST

Alan. It didn't work. It couldn't have -- among other things, the old
language can't tell visibility from implication.



From: Alan Cox
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 16:47:03 EST

The prototype generates a very convincing table set, and the tables generate
very convincing graphs. The information to work out what option needs another
as I've said for months



From: Eric S. Raymond
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 16:46:10 EST


I've *solved* this problem. I understand the constraints. I know
exactly what you will have to do to get the rest of the way, *because
I did it*.

I have built not just a "proof of concept" but a working
implementation so robust that it is in production use by three
different projects. And a substantial number of kernel developers are
using it now and reporting it good.

The good thing about working with developers like you and Dave Jones
and many of the other loonies on this list is that you are fucking
brilliant. The bad thing is that because you're fucking brilliant,
you're often also ungodly arrogant about second-guessing other
peoples' work -- you think your snap judgment or "proof of concept" is
somehow equivalent to two years of design, coding and testing by
someone who has been concentrating on the problem.

News bulletin: IT'S NOT.

Alan, don't talk to me about "proof of concept". Tell me about a
production-quality system, proven in use by people like Embedsys,
Webmachines, and the Compache project. Tell me you can duplicate what
CML2 does successfully before you run around implying my design
assumptions are full of crap.



From: Alan Cox
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 17:40:41 EST

No you've replaced the system with one thats much harder to understand and
forces new tools on people. The *interesting* problem to solve is keeping

the existing infrastructure there and getting the same kind of results.

Since the information is there in CML1 to generate the list of constraints
for any given option, its a reasonable assertion that the entire CML2
language rewrite is self indulgence from a self confessed language invention
freak.

Alan



From: Eric S. Raymond
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 17:08:14 EST

Alan Cox:
> Since the information is there in CML1 to generate the list of constraints
> for any given option,

False assumption...

> its a reasonable assertion that the entire CML2
> language rewrite is self indulgence from a self confessed language invention
> freak.

leading to a false result.

If you want to refute me, build it yourself. You'll get a valuable learning
experience. At the end of it, I'll have earned your apology. Not that I
expect to get it.



From: Alan Cox
Subject: Re: Disgusted with kbuild developers
Date: Fri Feb 15 2002 - 17:52:00 EST

> Alan Cox:
> > Since the information is there in CML1 to generate the list of constraints
> > for any given option,
>
> False assumption...

Do you have anything more constructive that "doesnt" to say

> If you want to refute me, build it yourself. You'll get a valuable learning
> experience. At the end of it, I'll have earned your apology. Not that I
> expect to get it.

Been there, done that, got the pretty graphs. Possibly the next step is to
redo the work into mconfig which already does pretty much anything we need
with the existing config files parsed using a real 100% genuine yacc grammar

Here's another example thread from the debate, one of the many arguments:

From: Nicolas Pitre
Subject: Re: Disgusted with kbuild developers
Date: 	Sat, 16 Feb 2002 11:06:49 -0500 (EST)

On Sat, 16 Feb 2002, Eric S. Raymond wrote:

> Jeff Garzik:
> > I consider CML2 an albatross now, and the maintainer does not listen to
> > feedback.
> 
> New FAQ entry:
> 
> * Eric doesn't listen to feedback.
> 
> Bill Stearns observed in February 2002 that "Eric has been very good
> about folding in changes".  In response to feedback from the kernel
> mailing list, Eric has:
[...]

Eric has selectively listened to feedback he found interesting and still 
persist in resisting most others.

You ignored mine so far, even if they are like the ones made by many others.

Make the whole thing ___***IDENTICAL***___ to CML1.
Do a formal translation of CML1 into CML2.

Show us that you are clever enough to do so, even if it's not particularly 
interesting and challenging to you.

Show us that you can listen to this simple feedback.

Acknowledge that the feedback went through.

Don't tell us that's not doable.  Do it and show us that you can do a 
perfect translation of CML1 into CML2 with all CML1 structural flaws.

Submit that, and only that.

Do you copy?  Please acknowledge that you listened to this very feedback.


Nicolas



From: "Eric S. Raymond"
Subject: Re: Disgusted with kbuild developers
Date: 	Sat, 16 Feb 2002 11:08:57 -0500

I listened.

Would you ask someone designing a new VM to make it crash and hang exactly
the same way the old one did?

Do you demand that a rewrite of a disk driver have the same data-corruption
bugs as the original before it can go into the tree, and tell the developer
to add fixes later?

Pragmatically, the point of rewriting a system is to *fix bugs*.

Let's suppose we ignored this point for a moment.  Let's also suppose
that what you were demanding were not rendered horribly painful and
perhaps impossible by the difference between CML1's imperative style
and CML2's declarative one.

How the hell do you possibly think I could possibly stay motivated under
that constraint?  Nobody is paying me to do this.  I'm a volunteer; I
need to produce good art, not waste time slavishly recreating old errors
just because a few people are unreasonably fearful of change.



From: Nicolas Pitre
Subject: Re: Disgusted with kbuild developers
Date: 	Sat, 16 Feb 2002 12:34:41 -0500 (EST)

On Sat, 16 Feb 2002, Eric S. Raymond wrote:

> Nicolas Pitre:
> > Do you copy?  Please acknowledge that you listened to this very feedback.
> 
> I listened.

Good.  We therefore can make progress.
By your comments below we now know that you listened and that it's 
extremely painful for you to admit the truth.  But you must understand the 
nuances if you want to go somewhere with CML2.

> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?
> 
> Do you demand that a rewrite of a disk driver have the same data-corruption
> bugs as the original before it can go into the tree, and tell the developer
> to add fixes later?

Your examples are flawed.  The person who fix bugs in the VM doesn't use any 
other language than the original one.  The person who do a rewrite of a disk 
driver doesn't change anything in the struct rational purpose of reading and 
writing blocks of bytes on a media.

> Pragmatically, the point of rewriting a system is to *fix bugs*.

Indeed!  However CML2 is __way__ more than only bug fixing.  If you qualify 
your current CML2 inclusion proposal as only "bug fixes" it's much too much 
under estimating the work you did and the effort you put in it.

I'm sure people will agree with the fact that the CML2 syntax is much more 
enjoyable to read and work with.  The fact that all frontends are using the 
same parser eliminates bugs already.  That's the part most people have 
nothing against.  For god sake submit those parts and leave the rest for a 
later discussion!

Admit that in the tremendous work you did, there are parts that people will 
disagree with.  Don't spoil it all by not separating things and only 
presenting it as a big unknown blat!

For people to have confidence in CML2 it must be proposed in multiple 
incremental changes -- changes that are small enough (either conceptually or 
physically) for people to be able to grok them without too much effort.  You 
must also be prepared to see people wanting to modify things in some ways 
you didn't think about along the process.  That's why only producing a 
strict CML1 --> CML2 translation would already be a big enough step for now.

> Let's suppose we ignored this point for a moment.  Let's also suppose
> that what you were demanding were not rendered horribly painful and
> perhaps impossible by the difference between CML1's imperative style
> and CML2's declarative one.

Do what's necessary so the translation is a near as possible and the result 
in say 'make config' is the same (same questions as before).  You certainly 
can do that with some bits of awk.  If you can't come with something 
similar, you're then already admitting yourself that CML2 is so big a change 
that people are right to be afraid of it.

> How the hell do you possibly think I could possibly stay motivated under
> that constraint?  Nobody is paying me to do this.  I'm a volunteer; I
> need to produce good art, not waste time slavishly recreating old errors
> just because a few people are unreasonably fearful of change.

First, by doing what I described above, you'll please more people than you 
can imagine.  Next you must be prepared to face the possibility that your 
art might not be adopted integrally.  You should be motivated by the 
percentage that gets adopted in the end.

When Al Viro decides to rewrite the VFS, he doesn't submit it to Linus as a
single big opaque patch to replace the old code at once.  If he did, he
would probably still be waiting for Linus to merge his art.

Note the nuance:  we don't criticize your art but rather the way you present 
it.  It might be the best configuration tool ever, but introduce it in 
incremental steps and leave some slack between them for those who didn't 
work on it for the last year to digest them.  Please be wise so not to waste 
your art.


Nicolas



From: Jeff Garzik
Subject: Re: Disgusted with kbuild developers
Date: 	Sat, 16 Feb 2002 11:37:14 -0500

"Eric S. Raymond" wrote:
> Let's suppose we ignored this point for a moment.  Let's also suppose
> that what you were demanding were not rendered horribly painful and
> perhaps impossible by the difference between CML1's imperative style
> and CML2's declarative one.
> 
> How the hell do you possibly think I could possibly stay motivated under
> that constraint?  Nobody is paying me to do this.  I'm a volunteer; I
> need to produce good art, not waste time slavishly recreating old errors
> just because a few people are unreasonably fearful of change.

If you are not prepared to evolve the system, you are not familiar with
kernel development...  Prove that CML2 is good and needed by breaking it
up into steps, reaching the final goal...  Good ole Al Viro's patch
progressions are an excellent example to emulate :)

	Jeff



From: Alexander Viro
Subject: Of Bundling, Dao and Cowardice
Date: 	Sat, 16 Feb 2002 13:29:57 -0500 (EST)

On Sat, 16 Feb 2002, Eric S. Raymond wrote:

> Would you ask someone designing a new VM to make it crash and hang exactly
> the same way the old one did?
> 
> Do you demand that a rewrite of a disk driver have the same data-corruption
> bugs as the original before it can go into the tree, and tell the developer
> to add fixes later?
> 
> Pragmatically, the point of rewriting a system is to *fix bugs*.

	That, folks, is a fine example of very common problem.
It's very tempting to try and force your ideas of How The Things
Should Be Done(tm) into the tree by bundling them with genuine
bug fixes and (more or less gracefully) refusing to split the
patch.  Anybody who had done serious work on the tree had felt
that temptation at one point or another.  No arguments - it's very
attractive.  Indeed, you don't have to defend every point of your
design and implementation - you can always point to Bad Bugs(tm)
that are fixed by the entire thing and obfuscate the objections away.
The trouble being, _SUCH_ _BUNDLING_ _IS_ _NOT_ _A_ _VALID_ _STRATEGY_.

	It had been tried.  Many times.  Sometimes it even got the
thing into the tree.  _All_ such cases had lead to trouble.

	There is another way.  It takes more efforts, it requires
readiness to defend every damn part of your design and it means
that you will have to deal with the sad fact that parts of that
design need to be redone.  It will take more time.  It will look
less sexy.  It may very well mean that somebody else will get
alternative design into the tree on the top of your efforts.
There are only two positive things about it - it is honest and
it leads to better tree.

	How does it work?  Simple - look at the path from original
tree to tree with your modifications.  And no, "one big jump" doesn't
count.  Think of the way your ideas can be split into parts.  Think
of the way obstructions to the changes can be split into parts.
Find small and simple changes that can go in right now, would improve
the tree and would make the rest of path easier.  And merge them.
If you find that it can't be done - think what needs to be changed in
the tree (or in your modifications) to make the split possible.
If you see that something is ugly and stands in the way - help the thing
to achieve the form it wants.  That may change all your ideas about the
right design for your modifications.  That's OK - it's a Good Thing(tm).
And merge the small changes.  Step by step.

	_That_ works.  Less glory; more time; more work.  And better
tree afterwards.  The code wants to get cleaner.  In many directions.
The trick is to pick the right ones and let the thing grow into natural
form.  Do that many times in the right order and you will get it where
you want it to be.  Quite possibly - in a better place than you thought
originally.

	Before you start saying that it's impossible - THAT HAD BEEN DONE.
Between 2.3.40 and 2.5.2 (about two years) we got pretty much complete
redesign of VFS,  along with the stuff that was plain impossible with
the old design.  Get the old tree.  Get the current tree.  Compare.  And
realize that more than half of the way was covered during 2.4.  Yes, the
total size of patches had been about 2 times larger than the size of
combined patch.  Definitely took a lot of extra efforts.  You know what?
It was worth the trouble.  Result is better than what I've expected.  And
a lot of things in the first iteration of design had turned out to be
useless - stuff that was there to work around the problems that got _fixed_
by cleanups at some point during these two years.  And I fully expect to
see the same thing happening with the stuff I'm planning and doing now.

	While we are at it, look what Rik is doing right now.  He has
a huge patch pretty much rewriting (what a coincidence) VM.  He had tried
to shove its previous incarnations into the tree whole-sale.  Saying that
it didn't work is putting it _very_ mildly - resulting fight is in l-k
archives and boy, was it nasty...  Look what's going on now - same splitup
and gradual merge strategy.  Sure, extra work.  Guess what?  The thing had
already become better from that work.

	As for your motivations...  If you are doing that for bragging
rights ("I've thought up a new design and now it's in the tree, exactly
as I envisioned it") - find something else to brag about.  Your strategy
is basically a sign of cowardice - you are fighting tooth and nail to avoid
gradual changes and the only way I can interpret it is that you are afraid
to let parts of your design stand on their own.  Not exactly a bragging
material, that...

---

And, skipping to where the thread seems to have ended, fortunately on a constructive note:

From: "Eric S. Raymond"
Subject: Re: Disgusted with kbuild developers
Date: 	Sat, 16 Feb 2002 09:52:02 -0500

Jeff Garzik:
> Impacting kernel developers' productivity and workflow because of this
> is more of what I object to...

I still don't get why you think CML2 is going to interfere with your
workflow.  Would you explain this to me, please?



From: Jeff Garzik
Subject: CML2 feedback (was Re: Disgusted with kbuild developers)
Date: 	Sat, 16 Feb 2002 10:33:53 -0500

"Eric S. Raymond" wrote:
> What problems do you have with CML1?  Name them and I will make sure
> they are not issues in CML2.
> 
> I've been begging for feedback for many months.  Pleases *get specific*.
> Instead of muttering that Eric refuses to listen, *give me something
> to listen to*!

(cc'ing Linus)

1) Remove global dependencies.
> source "arch/um/rules.cml"
> source "arch/i386/rules.cml"
> source "arch/alpha/rules.cml"
> source "arch/sparc/rules.cml"
[...]

All symbols should not be included on every config run.  The
architectures currently create their own master rules file, which then
selectively includes other config files.  You break this and remove
control (and flexibility) by enforcing something globally which was
previously done on a per-arch basis.


2) As discussed in December (as well as before and after that thread),
the --eventual-- direction to go is that a single file will contain all
meta information about a driver or set of drivers.  Config.help entries,
Config.in entries, Makefile rules, etc.  The idea is to group
information about a particular object in the same location.  So,
considering (a) that Config.help now exists and (b) this eventual
direction, splitting up rules and symbols into completely separate files
is not the greatest idea... when we eventually want to integrate rules
and symbols.


Take a look at what we find in Donald Becker's virgin source tree, in
winbond-840.c:
> /* Automatically extracted configuration info:
> probe-func: winbond840_probe
> config-in: tristate 'Winbond W89c840 Ethernet support' CONFIG_WINBOND_840
> 
> c-help-name: Winbond W89c840 PCI Ethernet support
> c-help-symbol: CONFIG_WINBOND_840
> c-help: The winbond-840.c driver is for the Winbond W89c840 chip.
> c-help: This chip is named TX9882 on the Compex RL100-ATX board.
> c-help: More specific information and updates are available from 
> c-help: http://www.scyld.com/network/drivers.html
> */

All the information is in one location.  Now, Linus said not to embed
this information in the source, but put it in a metadata file.  But
other than that, this is a small and simple example of what the metadata
config files might eventually look like.


So, my own personal opinion is that CML2 should follow these suggestions
:)

Regards,

	Jeff



From: Jeff Garzik
Subject: Re: Disgusted with kbuild developers
Date: 	Sat, 16 Feb 2002 10:36:21 -0500

"Eric S. Raymond" wrote:
> 
> Jeff Garzik:
> > Impacting kernel developers' productivity and workflow because of this
> > is more of what I object to...
> 
> I still don't get why you think CML2 is going to interfere with your
> workflow.  Would you explain this to me, please?

(please read "CML2 feedback" message before this...)

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.

	Jeff



From: Eric S. Raymond
Subject: Possible breakthrough in the CML2 logjam?
Date: 	Sat, 16 Feb 2002 10:52:19 -0500

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



From: Jeff Garzik
Subject: Re: Possible breakthrough in the CML2 logjam?
Date: 	Sat, 16 Feb 2002 11:34:29 -0500

"Eric S. Raymond" wrote:
> 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.

Global dependencies...  CML1 doesn't have this now, and it needs never
to have it.  This is no point in merging a design change of that
magnitude only to take it away later on.  Further, merging a rulebase
which contains such dependencies would be a huge mistake that might take
years to undo.  drivers/net/rules.cml doesn't need S/390 stuff in it,
AFAICT, and that is a simple example of a bug found in many of the
rules.cml files.

	Jeff



From: Eric S. Raymond
Subject: Re: Possible breakthrough in the CML2 logjam?
Date: 	Sat, 16 Feb 2002 11:57:39 -0500

All right.  There are a couple of ways we can attack this -- I have
some ideas.  But I want a meta-question answered first.  If we solve
this issue, *are you on board*?

I've got to get off the fscking treadmill I'm on now where I'm spending
so much time on the parallel-rulebase maintainance and the flaming
politics that I can't really get anything else done.  

After what you wrote upthread, I don't think you want me to be stuck
either.  Fact: ain't nobody else visible with both the motivation and
skills to tackle what you want done.  I've been thinking about
metadata-centered configuration and consciously bending CML2's design
towards it for longer than anyone else has even been considering the
problem.

I *will* get us there -- I think the last two years have demonstrated
my determination.  But to do it, I need alliance rather than
obstruction. I need you to tell Linus that your concerns have been met
and sponsor CML2 to go in, so I can stop perpetually re-fighting old
battles.

Because we agree on getting to metadata-centered configuration, your
requirements list now appears to have shrunk to one.  You want to
"eliminate global depencies".  I hear that.  I got it.  

What I want to know is that this is not a proxy for "CML2 can never be
good enough" and that you'll be pulling more objections out of your butt
till the Sun goes nova.  Because if that's true there's no point in
my trying to work with you. 

But if "eliminate global depencies" is it, we can be allies, because 
ultimately we both want to get the config system to the same place. 
I've taken the first, biggest step -- from imperative code to 
declaration/constraint language.  The second -- from a
declaration/constraint language to a metadata-centered system -- 
will be easier.

A positive answer may be "Yes, that's it, let's go forward", or
"Almost, there are a couple other minor and negotiable issues *which I
will now list*" (where "Minor and negotiable" = "I don't have to scrap
my architecture").



From: Jeff Garzik
Subject: Re: Possible breakthrough in the CML2 logjam?
Date: 	Sat, 16 Feb 2002 12:29:59 -0500

"Eric S. Raymond" wrote:
> But if "eliminate global depencies" is it, we can be allies, because
> ultimately we both want to get the config system to the same place.
> I've taken the first, biggest step -- from imperative code to
> declaration/constraint language.  The second -- from a
> declaration/constraint language to a metadata-centered system --
> will be easier.

Well, let's simmer things down a bit and see what other people have to
say.  Maybe I'm completely off base.

But to answer the question which the subtext seemed to asking (at least
to me), no, there is no vendetta against you.  And for the record on a
specific detail, I have no problem with python use.  If I have no major
objection based purely on technical grounds, that what you'll be hearing
from me.

And further, in 2.5.x series at least, minor objections can be worked
through after a kernel merge.  But major objections... that's not the
time when something -must- -go- -in-.

Regards,

	Jeff



From: Eric S. Raymond
Subject: Re: Possible breakthrough in the CML2 logjam?
Date: 	Sat, 16 Feb 2002 12:32:52 -0500

Jeff Garzik:
> Well, let's simmer things down a bit and see what other people have to
> say.  Maybe I'm completely off base.

Jeff, I'm not asking "other people".  I'm asking *you*.  

You're one of the people Linus says he trusts.  Linus has said,
explicitly, to myself and Dave Jones, on this very issue, "get me out
of the loop".  My take is that if you switch from opposing CML2 to
supporting it, the political wars will probably be about over.

I hope the prospect of actually getting to a metadata-centered
configuration system in our lifetime will be sufficient incentive for
you to do so.  Oh lovely dream...I could have a prototype
metadata-to-CML2-bus-guards translator in less than two weeks, I
think, if I didn't have to maintain the CML2 rulebase all by myself.  I
want to go there.

> But to answer the question which the subtext seemed to asking (at least
> to me), no, there is no vendetta against you.  And for the record on a
> specific detail, I have no problem with python use.  If I have no major
> objection based purely on technical grounds, that what you'll be hearing
> from me.

OK.  Is "global dependencies" your sole technical showstopper?  If so,
can we dispose of the ill-defined "CML2 will fuck up my workflow" thing?

If you tell me yes, we can move to a discussion of why global
dependencies are a problem and how to solve it.



From: Jeff Garzik
Subject: Re: Possible breakthrough in the CML2 logjam?
Date: 	Sat, 16 Feb 2002 14:01:09 -0500

"Eric S. Raymond" wrote:
> 
> Jeff Garzik:
> > Well, let's simmer things down a bit and see what other people have to
> > say.  Maybe I'm completely off base.
> 
> Jeff, I'm not asking "other people".  I'm asking *you*.
> 
> You're one of the people Linus says he trusts.  Linus has said,
> explicitly, to myself and Dave Jones, on this very issue, "get me out
> of the loop".  My take is that if you switch from opposing CML2 to
> supporting it, the political wars will probably be about over.

Shit... don't inflate my stock more than it's worth.

I'm not giving a pre-blessing to any, but I'm willing to give something
an honest and fair review.

	Jeff

---

To find the full thread, search for "Disgusted with kbuild developers" in any of the many online lkml archives. For example, you can find the start of the thread here or here.