Date: Sat, 18 Mar 2000 01:25:48 -0500
From: "Eric S. Raymond" <esr@snark.thyrsus.com>
To: linux-kbuild@torque.net
Subject: [KBUILD] Time for a bullet?

I've been examining the existing kernel configuration system, and I
have about concluded that the best favor we could do everybody
involved with it is to take it out behind the barn and shoot it
through the head.

Mind you, this is not intended as any sort of putdown of the people
who did it; mec and others have clearly labored heroically to adapt
the original design as the complexity of configuration has increased
and the three different configuration modes were implemented.  I bow
respectfully in their direction.

Unfortunately, the end result of their heroism is a brittle,
over-complex mess.  It's a mess of a very characteristic kind.  I
believe it was Alan Perlis who said that all programs that grow long
enough become first rococo, then rubble.  The present kbuild system
is, but definitely, in the rococo stage.  I think the collapse to
rubble can be expected sooner rather than later.

I found this out when I tried to add a facility for progressive
disclosure, based on the user's report of his/her level of expertise,
so that non-expert users could configure kernels without having to see
every single configuration panel for every single obscure feature set.
I gave up.  It was just too hard to change anything without breaking 
everything.

I think I may be able to solve this problem with a couple of weeks' 
work.  I've sketched a design, and implemented some sample code,
for a purpose-built configuration language that escapes the
limitations of the pseudo-bash that kbuild now uses.  Among other
things, the language would support 

(a) Optional use of checks against the output of dmesg(1) and lspci(1)
    to eliminate many questions in the common case where we are
    configuring on the same machine that will run the kernel.

(b) A common parser/configurator engine usable by multiple front ends
    (I expect to write two initially, one line-oriented like configure
    and one to run under X like make xconfig).

(c) Progressive disclosure.  By specifying some information about the
    goal of the configuration and his/her level of expertise, a
    relatively unskilled user will be able to get away with seeing
    fewer than 25% of the questions now presented.

Now for the hard question.  If I do a competent job at this, is it 
going to get used?  My path forward will lead to the obsolescence 
and complete scrapping of the present system.  There are three reasons
I can see why people might resist this:

1. Transition costs.  Some people may not want to learn a new config
   language, even though it will be less spiky and more expressive than
   the present one (that much I can already guarantee!).

2. Territoriality.  Some people with a lot of time invested in the
   present implementation may resist having it scrapped.

3. Implementation prejudices.  My incomplete protype is written in
   Python; I expect the full system will be as well, if I complete
   it.  I can imagine objections to this, though I'd think they would
   apply about equally to the use of tcl/wish in the present system.

So I'd like some feedback on these problems.  If the members of this
list are not willing to back a radical rethink of the problem, I doubt
I'll be able to sell it elsewhere.  Please tell me if you think I
would be likely to regret committing myself to this effort.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

Our society won't be truly free until "None of the Above" is always an option.

--  To unsubscribe, send mail to: linux-kbuild-request@torque.net --
--  with the single word "unsubscribe" in the body of the message. --