Slashdot Mirror
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.'"
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).
I can't say that I don't give a fuck. I've just run out of fuck to give.
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...
LedgerSMB: Open source Accounting/ERP
It's good to see some high profile hackers putting their minds to making GNU/Linux easier for people. This language should make it easier for hackers to fiddle with their kernel, and to get into kernel hacking, which is a great thing considering how daunting a challenge it is at the moment. It will also help people who have been playing with GNU/Linux for a short while start setting their systems up properly, instead of running on a hastily preconfigured kernel that came from their distribution installer.
It was promising then to see ESR say that he wanted this language to help GNU/Linux newbies. There's been a lot of good work recently on making the first steps more accessible, but there's been little progress in helping people who have completed the first challenge and who then want to get their OS running smoothly.
In order to install bind you must complete level 25, please try again.
Adventure games are soooo passe. I would prefer a Quake style interface with hidden buttons for config options. And maybe you could shoot all those stupid options that no-one ever uses. Like "Amateur Radio Support" and so on.
And if you configure your kernel wrong you end up in the Oops room with Colonel Panic. ?
Could be worse.. you could end up in the blue-fluffy-cloud room with General Protection-Fault.
dave.
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?
Why people keep inventing new pet laguages?
Whe he could not use GUILE, which is designed for things like this, adding domain-specific functions.
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).
You are suddenly surrounded on all sides by a dense blue fog.
You are dead.
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.
That obviously hasn't happened yet, but mostly only because Eric decided to implement CML in Python which a number of kernel hackers refuse to install on their systems (originally because it wasn't GPL compatibly licensed, and these days probably ostensibly because it isn't GPL'd, but more likely because it has icky syntax and they don't want to learn it or reconfigure their editors to edit it.)
Anyway, the idea was not so much to improve on xconfig, but to give you the ability to continue configuring your kernel once xconfig was no longer being maintained.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
Yet even with that "archaicness" I find kernel configuration in BSD to be easier. This isn't because I'm a canonical GUI-hating Unix guy; it's probably because I'm not. XConfig and particularly MenuConfig are excruciatingly tedious compared to opening your own kernel configuration file in one window in a text editor and the LINT file in the other. My FreeBSD configuration generally is a matter of commenting out a bunch of lines (mostly SCSI stuff) and adding two at the bottom for my sound card.
/etc/rc.conf file changes or overrides many things that Linux distributions tend to scatter around the system (often in places that change from distribution to distribution, no less).
I've honestly been very impressed with how logical the BSD configuration "system" is; it's not pretty but it's straightforward and easy to make changes to. The
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.
- Michael T. Babcock (Yes, I blog)
While Adventure is amusing, a Nethack/Angband-style configuration could be far more useful. The same room/object analogy could be used (town-level: different stores as sub-menus), you can check your inventory for current config, choose your race/class (arch/proc), etc etc etc.
.h and hordes .c ! Return victorious with the Amulet of bzImage!
When you are suited up and ready to battle, the compilation process could be initiated by entering the dungeon and watching gcc slay the demons of
Well, maybe that's taking it too far.
But if it got popular enough, maybe Blizzard would re-hash it in a fully-graphic real-time game for Windows.....
I know, I know.... "Don't moderate, reply."
The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool.
The current configuration tool *is* CML. The tool that ESR has produced is CML2. CML does its work with a mix of shell, perl, other tools. It's nasty. CML2 is pure Python.
That obviously hasn't happened yet, but mostly only because Eric decided to implement CML in Python
No, it hasn't happened yet because it's not material for a *stable* kernel series. It'll go into the development kernel, and all of the stuff that needs to be updated to make it work will get updated in the devel tree.
because it wasn't GPL compatibly licensed
Python has had a few releases that the FSF thought were not compliant, but Guido and co. thought that they were. Python has always tried to be GPL compatible. 1.5.2 and lesser are compatible, and so are all of the current newer branches of Python.
Anyway, the idea was not so much to improve on xconfig, but to give you the ability to continue configuring your kernel once xconfig was no longer being maintained.
The idea was to create a uniform set of configuration tools that got dependancy checking right and were easy to maintain. CML was none of those things.