Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Software

CML2 Coming in Kernel 2.5 190

Posted by michael from the make-config dept.
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.'"
This discussion has been archived. No new comments can be posted.

CML2 Coming in Kernel 2.5 More

CML2 Coming in Kernel 2.5

Comments Filter:

  • why no LL1 talk? (Score:2, Offtopic)

    by brlewis ( 214632 )
    ESR was previously going to be talking about this at the Lightweight Languages Workshop [mit.edu], but he's not on the agenda now. What happened?
    • I am not trolling or flaming, I am actualy passing on info I heard.

      From what I have heard from LUGs that want him to give a speech at, He is very high mantainance. He requires a nice hotel and good food, as well as a stipent in some cases, otherwise he will not come to talk....I have also heard that he gets a bit pissy over little problems in plans
    • Somebody thinks that a talk ESR was going to give on the topic of CML2 is off-topic re. CML2. Go figure.
    • I'm Mike Salib, one of the two organizer's for LL1. Basically we had a miscommunication with ESR. Combined with the fact that he's scheduled to be at other conferences both right before and right after LL1 a good distance away, he had to cancel.

      We're disappointed and so is he, but there's always LL2 next year ;-)

      Seriously, if you're in boston on saturday, you should come over. The whole thing will be videotaped and put on the web by DrDobbs and we'll also do a live audio webcast (probably) so everyone can watch.

      More info is available at LL1.mit.edu

      I have to go fail a signal processing exam now, but i'll be back later ;-)

  • Other Projects (Score:4, Interesting)

    by aridhol ( 112307 ) <ka_lac@hotmail.com> on Thursday November 15, 2001 @01:49PM (#2570154) Homepage Journal
    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).

    • Re:Other Projects (Score:3, Interesting)

      by Telex4 ( 265980 )
      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.
      • it would be a good project to try and extend ESR's idea to formalise config files for compiled packages.


        OK, so this thing reads a menu-definition file and spits out--what? A Makefile? An .c file? Something else?

        What I'm thinking is to have it read your menu-def file, and spit out a config-file creater and a parser.

        For example, you tell it you have a configuration option "FOO", which is a boolean value, and "BAR", which is a string. These are put in the menu somewhere. You run this through the config-generation app, which spits out two modules: one to create a config file, one to read it.

        Now you create the config file using whatever front-end you want (standard menu, graphical, Zork, whatever). Then in the app, you say something like getconfig("BAR"). The library is able to validate the entry (it knows that "BAR" is a string), and set a default (also from the generation script).

        Is this what CML does, or am I completely mistaken?
      • Isn't this pretty much what the Windows registry is supposed to be, minus all the worthless bloaty crap that gets stored there by ill-behaved applications? A central, OS managed place for applications to keep thier configuration info?

        • Re:Other Projects (Score:2, Interesting)

          by Telex4 ( 265980 )
          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.
          • Telex4, maybe you can tell me the answer to this: Does the Windows registry allow fine grained access priveledges? It seems to me that you have either allow every user full write access(unacceptable) or no access at all(unacceptable).
  • take nife
    [ but what with it? it's gross ... ]
    2 hours later, bitching, trying everything on everything
    sharp knife with grass
    [ found scanning through the game files]

    ---
    This is from Larry. What would one solve in CML2?
  • for including flight simulators in spreadsheet programs. Now we have adventure games in our kernel configuration system? I would hope this would be an optional add on.

    Not that I'm against this per se, I actually kind of like the idea, but only as a novelty. I kind of liked the easter eggs in MS programs too, but when they get to the point of introducing (noticable) added overhead either to disk, memory, or program maintainability I have a problem.

    So while it may relieve some of the tedium of kernel configuration. The first time make adventure causes a problem, I'd expect to get back some of the dung the linux community has flung over the years.

    • I think the adventure game is a front end for it, not in the actual code itself.
      • I think so too, and I'm sure there will be lots of front ends which spin off of this. I'm waiting for the OpenGL front end with acceleration and an Unreal engine.

        What I don't want to see is this being bundled with every kernel. IMHO the kernel distro should be a small streamlined product with enough in the way of configuration for people to get their job done easily. I think that while cool, adding a game front end is over the line of what's needed and wanted by the typical sysadmin.

    • 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.

      Contrast this with the flight simulator in Excel. It went in because some people at Microsoft wanted it, and it won't come out because no one else can make that decision. It would take a major effort by millions of irate customers to make Microsoft take it out; it just wouldn't be worth their while for less. Hell, the irate customers can't even make them fix real bugs. It's all they can do to make them fix security holes (sometimes *cough* Outlook *cough*). And now Microsoft wants people to shut up about the security holes. It's too much trouble for them. Why are you people bothering us about security? Can't you see we're busy writing the next version to take another billion from you?

      Hmm, that transformed in midstream from an essay on development paradigms to an anti-MS rant. I must be in Slashdot :)

      • "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.
        • The other piece, besides the skill to which you allude, is source code availability.
        • Except that any developer wants to can fork the project so that it does not include the easter eggs, thereby gaining all those users who are upset about such things. Whatever benefit that might have to such a developer I leave as an exercise for the reader.
        • That statement is only true if 'people' == 'developers compentent enough to maintain kernel code'.

          Or people who can hire or persuade such developers.

          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.

          99.9% of mainstream users will be unable to change the source directly, true. But follow the math here: if as few as 1,000 people want something changed, and 99.9% of them can't do it, that leaves one who can. Meanwhile, many of the other 999 will be bitching about it in various fora, which will probably influence others, especially if they have a legitimate complaint.

          Also, I would expect a certain positive correlation between inclination to be annoyed at a misfeature, and ability to do something about it. So I think your 99.9% figure is high.

          It is also at least possible for many sufficiently motivated people to learn how to program and influence an open project they care about. In any case, 99.9% unable to change open software is certainly better than 100% unable to change closed software.

          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.

          Given that most people can't program, can you suggest an alternative paradigm that would increase participation?

          Finally, it must be said: people who have paid for software, and are forbidden to fix it themselves (or hire someone to fix it), have legitimate cause for complaint if their vendor doesn't fix it for them. People who have gotten software for free, and are free to change it in any way they like, have no claim at all on the developers. "If it breaks, you get to keep both pieces."

  • Hmmm (Score:5, Interesting)

    by einhverfr ( 238914 ) <chris.traversNO@SPAMgmail.com> on Thursday November 15, 2001 @01:57PM (#2570196) Homepage Journal
    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...
    • I would say that you're right in thinking your reaction was due to your knowing shell scripting already. I suppose old hands will find this language either pointless or too much effort to learn, whilst those nearer the newbie spectrum will find it a godsend (assuming it's well written). IT'd be good to find a compromise though.

    • Re:Hmmm (Score:1)

      by tao ( 10867 )

      The problem with CML1 isn't readability, but expressibility. The language suffers sane ways to define dependencies. CML2 provides this. Of course, it's likely to take some time for people to get used to CML2, but then again, people still make a lots of mistakes with CML1...

    • what i never got, nor investigated, was why the config didn't use an autoconf, et al. TYPE of system. obviously it would have to be different.
      but i get really annoyed when each time i config i have to go into every single damn section to make sure shit i don't need is turned off. now of course i know how to move my .config files around. but i still have to check.
      i hope CLM2 can/will provide some structure to allow one global file that will provide my basic system structure and will turn off all the crap i don't want (am radio for instance i prolly won't use in the near future).
  • Is there a similar kernel configuration GUI for OpenBSD/FreeBSD/NetBSD?

    Editing BSD kernel configuration files has always been lousy and very archaical compared to Linux menuconfig and xconfig. I still can't understand why nothing was developped for BSD.

    • Because nobody's submitted the code for it.

      If you feel like writing this, go right ahead. Submit it as a PR. If it works, and it's reliable, it'll get picked up.
    • Primarily because the BSD's maintainers seem to prefer the configuration file. There are several things that distinguish BSD from Linux, and the Kernel Config file is a big one. You may find that not all OS quirks are due to technical roadblocks but to particular people's preferences.

      To use an analogy, Directors of movies like to step into the editing booth and make sure certain scenes/footage stay in the movie- sometimes not because they have merit on their own, but because the director wants them there.

      An often-overlooked aspect of the kernel community of the open Unices is the lack of true central authority. Before you flame, some OS's have stronger leadership than others, and some are ruled more by a group concensus than others. It seems a it obvious that this question came from a user who hasn't spent much time in the BSD 'community'. Spend more time there and I think this and many other questions will be answered, just maybe not the way you expect.
    • 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).

  • A promising step (Score:5, Insightful)

    by Telex4 ( 265980 ) on Thursday November 15, 2001 @02:00PM (#2570218) Homepage
    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:A promising step (Score:2, Informative)

      by rhekman ( 231312 )
      For those of us more experienced at building kernels, there is another project that is looking to make building kernels much better. That is Keith Owens' new kbuild architecture. He has rewritten the makefiles to make readability better, put compile time dependency checking in the right place, and make creating patches easier. It will work wonderfully with ESR's system and have the effect of making repeated compiles much faster. Anyway, I can't wait.

      http://kbuild.sourceforge.net/ [sourceforge.net]

      Regards
    • 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.

  • Kernel configuration as a game? (Score:3, Funny)

    by Araneas ( 175181 ) <pgilliland.rogers@com> on Thursday November 15, 2001 @02:01PM (#2570225)
    Very cool idea. Hmmm... now to screen out the L class users:

    In order to install bind you must complete level 25, please try again.

  • You can tell he's from the 80s (Score:3, Funny)

    by Anonymous Coward on Thursday November 15, 2001 @02:08PM (#2570262)
    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.
    • It seems like this would be possible. But in order to make it worthwhile there would have to have something fun like shooting monsters or racing other 'players' or whatever.

      BTW, I have and use Amateur Radio Support! I would not use a new kernel without it.
      • Wans't there someone who set up a version of Doom where processes on the system were represented by monsters. Killing a monster caused the process to terminate. It worked ok, except when the monsters started fighting each other...

    • Re:You can tell he's from the 80s (Score:1, Funny)

      by Anonymous Coward
      This is more doable than you might think. Quake 1 is open source now. All someone needs to do is make a "level" where you configure the kernel.
    • This is for real hackers bro. If you don't recognize all the commands, then you shouldn't be using the interface.

      (Ever read, "The Soul of a New Machine"? Starts out with someone going through, "You are in a maze of twisty passages that all look the same...")

  • An adventure game (Score:3, Funny)

    by spectrum ( 92555 ) on Thursday November 15, 2001 @02:10PM (#2570277) Homepage
    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.
    • And if you configure your kernel wrong you end up in the Oops room with Colonel Panic.

      Of course not.

      You have removed all disk support. It is dark. You are likely to be eaten by a Grue...

      > _
  • _________________________

    General Protection Fault
    _________________________

    > Kill fault

    With what -- your bare hands?

    > Yes

    Congratulations -- you have just made Windows a stable OS with your bare hands!
    Unlikely, isn't it?

    > Format c: /y

    You are in a maze of unallocated sectors, all alike.

  • Why not XML? (Score:3, Interesting)

    by Anonymous Coward on Thursday November 15, 2001 @02:17PM (#2570327)
    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?

    • Re:Why not XML? (Score:2, Insightful)

      by Black Perl ( 12686 )
      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.

    • He could probably have used XML, but that wouldn't have helped with the real problem, since the kernel config isn't really a simple tree:
      "(...) the kernel-configuration process has grown excessively complex. The configuration system's job is to turn the user's answers to configuration questions into a file of #define constructs used to condition features in or out of the C code. As Linux has grown more features and more driver support, the number of menus and prompts one must navigate to choose the appropriate subset of those features has become forbidding even to expert users, and outright impossible for the novice users Linux increasingly seeks to attract. To properly manage the complexity we have created, we need a configuration interface that can support better chunking and progressive disclosure. Ideally, novices building kernels should see only the choices they need to make. As they gain competence and cue the configuration system that they are ready, they should see more options for tuning and exotic hardware. The full process should be accessible to expert kernel hackers, but not inflicted willy-nilly on everyone else as it now is."
      (from the CML2 paper [tuxedo.org])
      So, the tool ensure that only sane kernel configs are built is where the real meat of the problem is. XML wouldn't be much help there.
      • So, the tool ensure that only sane kernel configs are built is where the real meat of the problem is. XML wouldn't be much help there.

        Why do you say that? That's the whole point of XML validation. You define up front what a sane config is (THIS is the meat of the problem) and express it in a DTD or Schema. Then you could use your favorite validator to determine if it was a sane kernel or not. In fact, you could use a standard XML IDE that could enforce the DTD/Schema to make sure you CAN'T create anything but a sane kernel!

        Instead, he's created another non-standard format and tool writers will have to create kernel config tools from scratch.

        • Yes, but how would you express all the different valid/sane configurations in a DTD?

          Have you looked at http://tuxedo.org/~esr/cml2/cml2-paper.html#AEN96 ?

          IMO, you would end up with something that generated a new DTD for each kernel version. And then the real work would be in keeping this tool up to date, so again, XML wouldn't get you anything spectacularily useful.

        • You define up front what a sane config is (THIS is the meat of the problem) and express it in a DTD or Schema.


          You can't.

    • XML is human -readable- but not easily human -writable-

  • another language? (Score:3, Interesting)

    by krokodil ( 110356 ) on Thursday November 15, 2001 @02:22PM (#2570347) Homepage
    Why people keep inventing new pet laguages?
    Whe he could not use GUILE, which is designed for things like this, adding domain-specific functions.

    • I'll point out that GnuCash has a Scheme-based user preference setting which does handle a lot of this, including different kinds of options, specifying defaults, etc. It doesn't really do prerequisite handling the way that CML does, though. But if I were going to rip off a user preferences config system from somewhere, I think I would start there.

    • > Why people keep inventing new pet laguages? Top 10 reasons why people are inventing new languages: 10. BASIC sucks. 9. C is too much limitated. 8. Assembler programs are too complicated - for most applications. 7. Perl... hmm, if You do not write scripts?? 6. PHP? Ok, if You don't program web servers. 5. Fortran: Hey, stoneage is over since several thousand years... 4. c# ? hohahahahaha 3. SQL can't do everything. 2. Java is too much standartisized. 1. Because they can. (c) simon@gleissner.com

    • Re:another language? (Score:2, Insightful)

      by psamuels ( 64397 )
      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.

  • to configure a +5 ethernet so I don't need to use the -60 WinModem.

  • 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.

  • From the LKML like above, included as the tag on ESR's email is this:

    .. a government and its agents are under no general duty to
    provide public services, such as police protection, to any
    particular individual citizen...

    -- Warren v. District of Columbia, 444 A.2d 1 (D.C. App.181)


    Is he asserting case law does not support the government offering public services (police)? Meaning, that the government is violating case law in doing so. Meaning, people dont have a right to public services? Meaning, the government's public services are "illegal" (or not a legal obligation)?

    Am i understanding this correctly...

    Sorry, this is very OT.

    • "to any particular individual citizen"

      It's well known that ESR is a huge supporter of the gun lobby, and he's showing that the police are not necessarily there to protect the individual, but rather to protect the general populace. He's trying to show that case law has proven the individual is responsible for their own personal protection, and further that laws restricting gun ownership are dangerous to the individual.

      I write this from a community which has banned handgun ownership altogether, but there has been no apparent reduction in firearms deaths or injuries.

      But I'm not bitter...

    • Re:OT (Score:1)

      by flink ( 18449 )
      What this decision says is that the police don't have to stop a crime in progress. i.e.: They are under no obligation to stop you from getting mugged, mudered, etc. Their job is to investigate crimes and arrest criminals, not provide protection (although they often do). If memory serves, (and IANAL) this was a case where some one was suing the police dept. because some officers witnessed a crime and did not offer assistance.
    • IANAL, IIRC, etc.

      This case involved a woman who was suing the DC police becuase they failed to show up in time to prevent her from being raped. The ruling held that government services are not responsible to help out in any specific instance, and that they are not liable if your house burns down or you get mugged and they fail to prevent it. The primary responsibility for protection falls upon oneself.

      I assume the invocation here is to argue that if individuals have primary responsibility for their own defense, they should be allowed the tools to do so.

      (Actually, that's a pretty good point. And, despite the horrificness of its syntax, it looks like this CML2 means I won't have to hit 'n' 5000 times as menuconfig asks me if I want support for every sound card on the planet. It's rare that I have one positive thought towards ESR, let alone two at once.)

  • Somewhere along the line, somebody, somewhere, will drop some networking code into the kernel config module, and hook up with other 31337 h4x00rz...

    You: Damnit, I've been waiting 2500 clock cycles for this damned PCI_BUS to spawn.

    n00b: Hi! I'm new here. OooOoo, can I have that?

    You: Have what?

    n00b: Your uber-leet PACKET_FILTER sword of destruction!

    You: *eyes narrowed* I thought you said you were new here?

    PCI_BUS spawns, and aggros the n00b.

    n00b: Take that, PCI_BUS_00! I'll configure you!

    You: Hey, I've been camping that!

    n00b: victorious in configuration - it aggroed me first, 10053r. Go camp the EISA_BUS instead. *snicker*

    You: *grumbles*

  • How about the Inverse Problem? (Score:3, Interesting)

    by Anonymous Coward on Thursday November 15, 2001 @02:34PM (#2570423)
    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).
    • I had the impression that the inverse is an eventual goal for ESR and Owens. I think it's stated in the future goals' section of ESR's paper.


      You are correct in saying that this would make newbie use of the kernel much simpler. However, one step at a time, my son...

    • If you select a network card, networking would get enabled, etc. because of the built-in dependancy tracking -- you can download versions of CML2 for kernels 2.4.x and try it yourself.
  • I've used xconfig (and to a lesser extent menuconfig) and I found them more than adequate. My only gripe is that the help text is not defined for all the options (though all the major options have excellent documentation that you can display by pressing the help button). So, I don't mean to knock CML2 but what's in it for me? And are there screenshots anywhere?
    • I think CML2 includes the ability to build and install the kernel and modules in one nice neat package....but I am not sure
    • The CML project got started when kernel developers started complaining about how hard it was to maintain the current configuration tool. The idea was to stop maintaining xconfig (and brethren), and move wholesale to CML.

      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.

      • Re:What's wrong with xconfig? (Score:4, Informative)

        by MSG ( 12810 ) on Thursday November 15, 2001 @09:35PM (#2572827)
        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.
    • As a user, there appears to be no difference. The kernel maintainers see the difference.

      CML is a way for the kernel hackers to tell the config system what options you see when you type "make xconfig".

      The kernel-hacker writes some CML code, which he then compiles into a config file. Then, you run xconfig, menuconfig, advent, or any other frontend that gets created, and you have a configured tree. And when the kernel-hacker adds a feature, there's less chance that he'll break configuration dependencies.
    • 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.
  • As far as I recall one of ESRs objectives in designing CML2 was to make the configuration process more intuitive. Some people even questioned here to include this into their projects. So I ask myself how configuration systems should look like in future.

    Regarding desktop Systems there are quite a few things the Users seem to want:
    • Fast configuration
    • Ease of use
    • Similar configuration mechanisms for all Aps

    Some of these points were met by Automake/Autoconf/Make in our todays Apps, but there is a further point, a clear structured development. This is something, which was not possible with Automake/conf and make, because you had several levels, which could be affected by errors.

    I haven't had the time to investigate CML2, but some people seem to believe it to meet this needs. after having most Linux distributions have unique Package Management by now, we might have reached a point which enables us to realise the need of unique and clear configuration Systems in all OpenSource Software.
  • I believe my .sig is appropriate here...

  • Simple intelligent kernel config for newbies (Score:3, Interesting)

    by 2Bits ( 167227 ) on Thursday November 15, 2001 @02:50PM (#2570519)
    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.
    • 90% of the time I configure a kernel, it's for a *different* machine.

      Thanks to modules, regular users do not generally need to configure kernels. CML is most often used by people like me, who play with esoteric hardware and regularly apply various kernel patches, messing with the code in the process.
  • A site I maintain ( http://rejuvenation.com/ [rejuvenation.com] - a lighting manufacturer ) has hundreds of products that have separate configuration with their own constraints and logic. Though I'm squeaking by with our current online solution (PHP translations of configuration files created by a proprietary product), I've been looking around for a good standard in which to create an alternative solution. This might be it? I'm not sure, but it certainly looks like it could be.
  • I new adventure game!

    And I thought "make config" was enough like a adventure anyways!

    ttyl
    Farrell
  • CML2 may be as ready for Linux 2.5 as it can be, but that doesn't matter one bit if Linus doesn't want to take it. It seems to me ESR is taking it for granted that this will be the next kernel configuration scheme, but what's the word from the main man himself? I haven't heard a word about CML1 being replaced, but then I really don't follow the LKML too closely.

    I imagine there would be quite a few oposed to this, especially if Linux now needs to ship with Python as well.
    Would it perhaps be feasible to to compile the CML2 parser, and just ship that binary for those that don't want to install Python as well? Or does someone have other tricks up their sleeve?
    • Would it perhaps be feasible to to compile the CML2 parser, and just ship that binary for those that don't want to install Python as well? Or does someone have other tricks up their sleeve?

      In the cited document (I know, it's a long, technical, and only semi-interesting read), The CML2 Language, ESR says this about that:

      Python, unlike other scripting languages, can be (effectively) compiled to pure C using the freeze facility. The translation is not pretty, and produces rather large C programs from even small Python sources, but it does meet the problem of portability head-on. Kernels could be shipped with a precompiled rulebase and a frozen C version of the CML2 interpreter to avoid the requirement for Python.

  • If memory serves, there was a column in DEC Professional years ago (obviously) that jokingly likened the RSX-11 SYSGEN process as an adventure game. Now something like that's finally available!

    I'm sort of wondering how long it'll be before I see ``Munging the SCSI adapter has no effect or what ``Hello, sailor'' does to the kernel. And, yes, I know, those are more from the Zork games. Just can't remember any of the good funny responses from adventure any more. Other than the one about the maze of twisty passages, of course.

  • An even better interface (Score:4, Funny)

    by theLime ( 4908 ) <andrewduhan@gma3.14159il.com minus pi> on Thursday November 15, 2001 @04:56PM (#2571183) Homepage
    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.

    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 .h and hordes .c ! Return victorious with the Amulet of bzImage!

    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.....
  • If CML2 is interesting from the very technical point of view, for its benefits, his flexibilty and his scalability of the configuration language itself, the fact that it requires Python2, just SUCKS.
    The linux kernel needed CML2 to solve some known problems, and to ease the build of new kernels, but didnt needed a requirement of 50 additional Mbytes (python 2), that all of the Linux vendors will have to ship now (I also think about embedded systems on this issue).
    This packages is very NON-standard, except maybe on Debian, and a port of CML2 in C would be way more logical IMHO (or at least, in Perl, because it's much standard these days (autoconf needs it too)).
    I'm curious to see the arguments of "Mr ESR the hacker, author of amazing software from kernel space to user land like fetchmail or the insane gif2png" on the real tech needs to use Python2 over something else on this issue.

Slashdot Top Deals

Kiss your keyboard goodbye!

Close