"Eric S. Raymond" wrote:
> The project is not yet complete, but it has reached a beta stage at
> which it is usable and in significant ways functionally superior to the
> present system. I am confident that it will complete. I am announcing
> now rather than holding off until I'm completely done because there
> are some preparations which, if begun now, will significantly reduce
> total transition costs. These preparations will *not* break the
> present kbuild system.
>
> Why this project at all? It all started when I realized that building
> kernels is way too hard. I wanted to simplify the configuration task
> enough to make configuration accessible to non-gurus. It needs to
> have more policy options. Rather than hundreds of questions like
> "Include FOOBAR2317 driver?", the novice should see stuff like
> "Compile in all modular drivers as modules without prompting?"
IMNSHO this attitude is wrong. If building the kernel is tough for
newbies, make a userland utility with all these policy questions and
features. We are talking about an interface on the KERNEL DEVELOPER
side of the line.
I am all for making the kernel build and config process more flexible,
but I am NOT at all for "dumbing down" the interface just so to make it
easier for newbies to build a kernel. If a person does not understand
the issues related with building a kernel, they should get someone else
to do it for them. That's why distributions and vendors exist.
> This just can't be done with the existing kbuild system. The existing
> config-language programs are hard to read and modify,
huh? compared to what ? It is simple to read, simple to modify. The
major nasty issue right now is dependencies not readability.
> and the code
> that interprets them has become a huge, unmaintainable hairball of
> Tcl/Tk, C, makefiles, and shell. It has all become terminally
> brittle, and the maintainers agree that it needs to be nuked and
> rebuilt from scratch.
100% agreed.
> It happens that I love writing domain-specific minilanguages, so I have
> tackled this problem head-on. I have designed a new configuration
> language I call CML2 (the existing language I have retrospectively
> named CML1). The implementation has two parts:
[...]
> The major source of problems is, as you might expect, that 6747-line
> mass of old code -- the new language is nontrivially different than
> the old, and the CML1 corpus is so tangled and nasty that I am certain
> I have made at least a few mistakes in the translation. There are
> a couple of places where I didn't understand the author's intentions
> well enough to translate some particularly grotty CML1 code. I'll need
> some help untangling these knots.
Don't worry, it's to be expected.
> Tcl/Tk, and Makefiles, CML2 is all be written in a single language
> (Python).
Yet another tool...
> 4. Eliminates (or at least drastically reduces) lag between port configurations
>
> The fact that the top-level CML1 files of the nine ports in the kernel
> tree are separate means there have been plenty of opportunities for
> the common code in them to suffer from version skew -- I point out
> about a dozen bugs of this kind in the list of errors at the end of
> this post. CML2's design and compilation rules should effectively
> prevent future bugs of this kind.
This definitely needs to be cleaned up, since some of the arch config.in
code exists solely to work around problems which [presumeably] don't
exist in yournew system.
However I think that getting rid of the top-level arch files entirely
will make for administrative headaches. Make sure you communicate
thoroughly with the port maintainers on this one...
> 8. Policy-based options
>
> The declarative semantics of CML2 makes it much easier to set up
> and check interdependencies among symbols. I have done only
> enough of this in the CML1 translation for demonstration purposes (there
> are new symbols TUNING, EXPERT and WIZARD that change some visibilities).
> Once CML2 is in place, it should be a relatively small effort to
> give the user a rich set of policy and don't-bother-me options.
IMHO this shouldn't be in the new system. Make a userland utility
outside of the kernel tree which does this. I think there are already a
few kxxx or gxxx GUI utilities for newbie kernel configuration.
Kernel configuration issues, even under your new system, will always
require a certain amount of knowledge about the kernel in general.
Newbies will lack some or all of this knowledge. Doing this sounds like
it will increase the number of garage bug reports send to lkml...
> I have designed the CML2 implementation to coexist with CML1, so both
> methods can be used while CML2 is being field-tested and debugged. I
> anticipate a phase-in over three or four point releases during 2.5.x,
> followed by a back-port to 2.4.x. Once CML2 is reported OK by the
> various porting groups, Linus can quietly nuke the CML1 machinery.
>
> There are a couple of preparation steps that can fruitfully begin now
> and should happen before 2.4 in order to minimize backporting hassles
> later.
All this can be done post 2.4. Let's break _less_ not more
configurations now.
> 1. Notably, I would appreciate it if config-file maintainers made
> the following changes in those files and relevant C code:
I'm sure you mean to say,
"Do the following changes look acceptable to the relevant code
maintainers?" [you say in a mail cc'd to the arch or driver
maintainers]
> CONFIG_6xx -> CONFIG_PPC_6xx
> CONFIG_4xx -> CONFIG_PPC_4xx
> CONFIG_PPC64 -> CONFIG_PPC_64
> CONFIG_8260 -> CONFIG_PPC_8260
> CONFIG_8xx -> CONFIG_PPC_88x
> CONFIG_060_WRITETHROUGH -> CONFIG_M68060_WRITETHROUGH
> CONFIG_21285_WATCHDOG -> CONFIG_DC21285_WATCHDOG
> CONFIG_3C515 -> CONFIG_ISA3C515
> CONFIG_8139TOO -> CONFIG_RTL8139
> CONFIG_82C710_MOUSE -> CONFIG_CT82C710_MOUSE
> CONFIG_977_WATCHDOG -> CONFIG_WB83C977_WATCHDOG
> CONFIG_3215 -> CONFIG_IBM3215
> CONFIG_3215_CONSOLE -> CONFIG_IBM3215_CONSOLE
>
> The reason for these is that CML2 symbol names drop the CONFIG_
> prefix. It's unneeded clutter, and made CML1 programs harder to read
> (the eye-brain systems that handle spelling look for prefix matches to
> recognize things).
You drop the CONFIG_xxx prefix? That's not something you do lightly,
nor is it something you toss off as an aside. CONFIG_xxx is an
important namespace convention and exists in a lot of existing kernel
code.
> Also, I had to change the KEYBOARD and MOUSE symbols used in the MIPS branch
> to MIPS_KEYBOARD and MIPS_MOUSE. This is because the MOUSE symbol
> seems to be used in different ways on different architectures (notably
> in the Intel branch).
An example of where merging completely independent config.in paths (Mips
and Intel) causes a conflict :/
> Port maintainers and others with a continuing interest in the development
> of CML2 should probably join the kbuild list -- subscribe in the usual
> way via linux-kbuild-request@torque.net
You should CC maintainers when their code is being discussed or
updated. The onus of effort is on YOU to make your changes known.
Otherwise you imply an unscalable model where maintainers must track
every mailing list that could potentially discuss and affect their code.
Overall, I think it is high time that the config system was rewritten.
While you are doing so, please consider two suggestions:
* It would be nice to be drop to add a new kernel module to the build
without patching a single file. For example, instead of adding
drivers/char/foo.c and patching drivers/char/{Config.in,Makefile}, the
patch to Linus would simply add drivers/char/foo.c and
drivers/char/foo.module. foo.module would contain configuration and
build information normally found in Config.in and Makefile. Doing this
implies some sort of collection step occurring, before the configuration
and before the build.
* Replace current makefile system with one which automatically generates
"one big makefile", from meta-Makefiles found in each subdirectory.
This allows make to generate a complete directed graph of the entire
build and all its dependencies, which eliminates some inherent make
problems, and greatly adds to the flexibility of the build process.
More later when I drop your config system into a test kernel.
Jeff
-- Jeff Garzik | Liberty is always dangerous, but Building 1024 | it is the safest thing we have. MandrakeSoft, Inc. | -- Harry Emerson Fosdick- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:12 EST