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

A promising step

[Telex4]

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.

Re:Why not XML?

[Black Perl]

Well, you'd still have to create a DTD or Schema representation; you just wouldn't have to create a new syntax.

But I agree. There's no reason why he had to invent a new syntax, when CML2 could have been defined as an XML application. Like you say, there's plenty of tool support.

Widespread acceptance

[Moooo Cow]

"Well, it is optional, but as a gedankenexperiment, let's suppose it weren't. If something gets into the kernel (or any other open project), it's because people want it there. If it isn't made optional, and no one forks a version without it, it's because not enough people dislike it enough."

That statement is only true if 'people' == 'developers compentent enough to maintain kernel code'. If Linux is to gain widespread acceptance, then for 99.9%+ percent of the population, it will be equally difficult to remove an easter egg from the Linux kernel as is to remove the flight simulator from Microsoft Excel.

I believe it is the development paradigm you are espousing here that is one of the largest roadblocks to mainstream acceptance - you've implicitly excluded the large majority of the 'people' who could be using Linux, without even noticing that you did.

Re:A promising step

[wrinkledshirt]

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.

I don't know that I agree. What we've essentially got here is yet another language that a user needs to learn in order to take advantage of something that's supposed to make the user's life easier. It's like forcing a student to study thermal dynamics so that they can learn to put gas in the car tank. It's this approach to making things user-friendly that Linux has been taking for a long time now, and it's only making things worse the more applications and tools show up.

Windows may have it's sucky points, but it's pretty much always click-point-click-scroll-click to get something set up. You can't get easier than that. Yes, it limits the interface for the user. For a potential hacker, I know that's a problem. For an end user and help-desk technician, it is a wonderful boon.

In my opinion, a completely radical approach should be taken -- all config and setup scripts as XML files. That way, you've got one DTD binding you to whatever you're trying to set up, and a protocol that you only need to learn the nuances of once.

Re:Something similar for BSD?

[Watts Martin]

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.

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

Re:another language?

[psamuels]

Whe he could not use GUILE, which is designed for things like this, adding domain-specific functions.

Uh -- CML2 is not a programming language, per se, but a language for representing a dependency graph for configuration options.

I fail to see how either XML or Scheme would be at all useful there. You would still have to invent conventions for how to store the graph, so instead of a language invented out of the blue, you get a language in XML or S-exp syntax invented out of the blue.

If anything, you should be advocating Prolog, which (unlike Scheme or XML) is a rule-based language, somewhat similar in semantics to CML2 data files. What's that, you say? Not enough people know Prolog? You can't be expected to install a Prolog compiler just to build a kernel? My point exactly.