CML2 Coming in Kernel 2.5

MrHat writes: "Eric S. Raymond's CML2, or 'Configuration Menu Language' -- part of the next-generation Linux kernel build system -- is now officially ready for 2.5. CML2 includes a compiler for a domain-specific configuration language, used to configure kernel subsystems and resolve dependencies between them. CML2 and Linux 2.5 will 'ship' with several different configuration interfaces, including an adventure game, whipped up by ESR during an extended flight. The story from the horse's mouth (or LKML, if you prefer):'This release resolves all known logic bugs and rulebase problems. The only things left on the to-do list are convenience features and some minor improvements in the test/coverage tools. This code is now officially ready for the 2.5 fork.'"

Other Projects

[aridhol]

The other examples posted on ESR's page are for kernel-oriented projects. How hard is it to stick this in another project? Something slightly smaller-scale than the kernel?

Also, this seems to only be concerned with compilation-time configuration. Although pre-compilation config is important, how hard is it to adapt this to work after compilation? If another app could use this configuration engine after it's been compiled and distributed, it may make it easier to customize pre-compiled packages (RPMs, DEBs, etc).

Hmmm

[einhverfr]

I read the article and I was immediately impressed at how much MORE readable CML1 was... Perhaps because I know enough shell scripting to follow it in my head. CLM2 was impossible for me to quickly follow what was going on and I had to think about it quite a bit more.

I think the basic idea of CLM2 remains sound, but I wonder if it will result in more "cutting and pasting" rather than direct editing...

Re:Other Projects

[Telex4]

Post compilation, configuration can only really be done with configuration files, like those used by LILO, XFree86 and various other apps. At the moment, you're right, there's no standard for the layout and internals of config files, and no standard program to interpret them. Some of the biggest steps forward have been made in this area in GUIs like KDE and GNOME, where configuration has been made simple and accessible. Although it would be a mammoth task given the number of config files in any OS already, it would be a good project to try and extend ESR's idea to formalise config files for compiled packages.

Why not XML?

[Anonymous Coward]

If it's a tree then why not use XML? I mean there are hundreds of tools available right now on every platform - why bother making your own language?

another language?

[krokodil]

Why people keep inventing new pet laguages?
Whe he could not use GUILE, which is designed for things like this, adding domain-specific functions.

Better, I hope.

[rice_burners_suck]

It would be great if this makes Linux kernel configuration easier and more flexible. With all the things Linux is designed to do nowadays (that is, operate on pretty much everything from a wristwatch to a computer the size of a building and everything in between), with so many different processor types and kernel configuration options, it must be a nightmare to configure a kernel from scratch. Hopefully CML2 will make this process easier for everybody.

Python ?

[Anonymous Coward]

Sorry ESR, but I don't want to install Python to be able to configure and compile the kernel.

How about the Inverse Problem?

[Anonymous Coward]

One issue for newbies with the current linux kernel configuration is the "inverse problem:"

I want feature X, what requirements will enable me to select it?

A trivial example: 2.4.0 required "experimental features" to allow resiserfs to be selected.

I hope that CML2 will alow for searching for and selecting choices anywhere in the decision tree, and "pushing-up" the requirements imposed by the decision (or pointing out problems).

Re:Other Projects

[Telex4]

Yes, it is. Making a GNU/Linux registry would have its ups and downs - the downs probably outweighing the ups. The up would be that it would make using the OS a lot easier for newer users. The downs would be that it would be hell to implement, it would put a lot of developers off, and it would make cross-platform compatability harder to achieve.

Simple intelligent kernel config for newbies

[2Bits]

Why can't we have a very simple but intelligent suggestion for newbie kernel config?

For example, the utility starts by doing a hardware diagnostics first, to see what does the system has. Then ask a few simple questions on the normal usage patterns, like

- Do you have any plug-and-play hardwares that you plug in on run-time?
- what kind of pnp hardwares?
- do you do multimedia?
- ...

Then base on the user answers, just come up with an "optimal" configuration, and ask for the user's approval (you may want to tell the user the reason behind this config, e.g. put the sound module as loadable module, because the user said s/he is using sound only once a while). Then compile the kernel for optimal performance for the user's specific hardware configuration and usage patterns.

Re:What's wrong with xconfig?

[MikeBabcock]

The current configuration system is really bloated and hard to maintain, especially for new module coders. The main thing that CML2 did first was to organise the configuration dependancies and information into a logical system that's consistent across the kernel. More importantly to me though is that it has a 'solver' if you will in it. It can 'prove' that a given configuration is valid before you go through the rigors of a 'make bzImage'. This keeps you from selecting options that unselect others (without telling you first) and makes it easier for module maintainers to code in these dependancies themselves.