Kernel Configuration via XML?

dpinckard asks: "Recently, I read an article on the Web (may have been on /.) that the configuration of the newer kernel releases is getting very unwieldy. The section that interested me the most was that there still isn't a good application for configuring the kernel that works from release to release. I'd like to make a suggestion: create a directory in the source tree and each code maintainer put their config info there as an XML file. I foresee this as easing the requirements of rewriting the config app when major module rewrites happen or even when new modules appear. The app just reads all of the XML files and builds the menus." Is this a good idea or not? What do you think?"

Mac OS X DP3

[kneecap]

isn't Mac OS X going to use XML to their config files in /etc/ and /etc/rc*. I seem to have seen something about that over at arstechnica: Mac OS X DP3 [arstechnica.com] . It would be the next logical step to configure BSD kernels the same way. This might be some thing we will see in Linux 3.0 or 2.6 if there is enough interest. Or maybe we will see it in one of the cutsy distributions, ie: Corel, SuSE, Caldera, etc..

Re:KML?

[NiteEyes]

Um, I hate to sound like a "me too", but...

Yeah, right on! I'm amazed some distro hasn't tried to do this yet. There are more ways to innovate besides the initial installer.

Standard XML config file would be hard between the kernels because of so many different features, as well as the same. But it's a great idea, none the less...

Has this every been discussed kernel dev list?

[supton]

If not, it should be. From my perspective, it would be a lot easier to do custom kernel configs using XML-based description files; any administrator with perl and ngsmls could then write quick and dirty compile scripts to duplicate their module setup when upgrading to new kernels. Not only this, but it would allow for someone to do gtk and qt based gui configuration programs that would be much better than the tk based 'make xconfig.'

Just a thought...
Sean

Yes!

[naasking]

XML is one of those truly wonderful things(called standards) which are incredibly useful, but which no one touches, because they try to push their own "standards" or try and maintain the current model.

Using XML in the kernel build process instead of large build scripts is one of the many potential uses of XML. This can be used as a springboard to more widespread adoption of XML in other applications. Once people see the true power of XML, they will be more inclined to incororate it in their apps.

-----
"I will be as a fly on the wall... I shall slip amongst them like a great ... invisible ... THING ... !"

Re:Why XML?

[kcarnold]

I don't see how XML would help the specific situation you note of building a single module in the tree. The configuration is a complex, interacting set of different parameters, for which XML might help to alleviate some of this complexity, but the problem of building a specific module is that there are many different configuration options that may apply to that module, for which the .depend's would work well. Possibly a differnt sort of restructuring is in order: configure each modularized part of the kernel individually (doesn't necessarily have to be compiled as a module, but anything with the capability of being at least partially split from the rest of the kernel), and then from the configuration decisions for each module, an overall set of configuration options can be developed. Note that menuconfig already largely does this, but its handling of dependancies is what makes me suggest a new format. This way, only the specific part of the kernel that you want to compile will be configured, and then you can selectively compile just that part without messing up anything else. Possibly this involves a modification to the makefile, to be able to smartly handle something like 'make ne.o', or even 'make module' ("Select a module to compile:", list), as opposed to or in addition to the existing 'make modules' (which simply recurses through all the kernel directories and runs 'make modules' there).

As for XML on other configuration files, there is of course the problem of the XML spec. Though the main idea is the same, one type of XML document can look very different from another XML document. Thus there would still be a problem with different config files. Moreover, each program would have to largely write an XML parser, even if it used a shared library for the purpose. Further, there is a natural difference between how programs are configured. Some programs fall readily into a key:value-type ordering (in which case the Windows .ini file works quite well), while others are much more variable (like the driver list for sane -- that should be on separate lines). I agree, however, that there should be a standard for how config files are done. I see a few different general types that can all be reduced to one general format:

key [whitespace] value
key:value
key=value

In this case, I recommend:

key=value

since '=' is not often used in 'value'.

Also, any subsections should be keyed like XF86Config (Section... Subsection...EndSubSection...EndSection), to allow for multiple layers of sections.

Any takers to draft a standard? Has one already been made? Anyone want to write a shared library to parse whatever?

Yeah -- Ken

XML config

[rodentia]

One of the original suggestions of a use for XML was as a means to bring order to the blizzard of .*rc and config files in the *nix. As someone here pointed out, Mac 10 will be using this format for the data formerly known as the resource fork.

As someone else noted, a standard schema for config files across different kernels could be useful, but would in fact be redundant effort because once you have XML, transformation into a different content model is next to trivial. In point of fact, modification of the kernel would be unnecessary as proper stylesheet processing could write the config and .*rc files in whatever form required by your kernel of choice. Is this worth the effort? I'll leave it to others, I'm merely a markup theorist.

XSLT: its not just for serving to old browsers. Use it. [apache.org]

That's what we have

[The Pim]

Modulo XML and some small details, what you describe is what already exists. The hard problems are the semantic ones, and XML won't help you a wit there. Nor will XML magically create you a nice, usable interface.

Re:Why XML?

[drix]

XML wouldn't make the actual config file a lot more useful (OPTION=(Y|M), yawn) but it could spread through other parts of the kernel and simplify them a lot; namely the build scripts which are a bitch to follow hard to adapt to your situation e.g. have you ever tried to just build a single module in the tree? G'luck.. I see XML having some potential uses here. I agree that XML isn't necessarily a panacea, but I don't think it's intended to be; rather, it's just supposed to be a extremely versatile and eXtended language that can be used for most anything. Think about how much easier our lives would be if all config files adhered to a set standard. No more arcane, abstract syntax created on the whim of some hacker. My god, I might even switch back to sendmail :)

--

KML?

[dlc]

Now here's a thought: what if there was a generic XML dialect (KML (Kernel Markup Language)?) that wasn't Linux specific -- if the maintainers of the Linux kernel, HURD, and the BSDs were able to come together, decide upon the standard feature set (without the specifics of implementations, i.e., modules as opposed to microkernel plugins) of modern kernels, and create an XML specification that would be valid across different kernels? Something where I could say, for instance, "give me PPP support, sound support, and ip masquerading, but not NFS or automounter support in my kernel", and have the same KML file be interpreted correctly whether I am compiling Linux, OpenBSD, or HURD. Now that would be groovy -- for those of us that need to run different platforms or different machine types.

Of course, I have no idea if this is feasable, it just seems like a pretty cool idea to me.

Cthulhu for President! [cthulhu.org]

Interesting, but is it necessary?

[dlc]

Over the last few months I've rebuiltmy kernel many times. often to try new features, or just to see what the differences were between stable and development, for example. I've found that the first few times are difficult (thank goodness I've had someone to give me a hand), but after that, I really haven't had a problem. Perhaps the kernel configs are getting a little complicated, but I don't think that means someone should write a markup language for it.

Besides, isn't the whole thing already managed by individual makefiles? Each developer adds a makefile to the subsection holding their module, and make calls the targets recursively? ls -R /usr/src/linux-2.3.51 | grep 'Makefile' | wc -l gives me 256 Makefiles, so that seems to be how it works.

darren

Cthulhu for President! [cthulhu.org]

Why XML?

[kcarnold]

XML is not some sort of magic panacea for all conceivable problems (though a good number of companies market their 'XML Solutions' as being such). I'll stay with the traditional format (yeah, you move everything over to a new format -- so what if it's archaic; it works without significant effort).

The only problem with the old system that I can see is patching. When you have multiple patches to your kernel, patch might not be able to integrate a context diff into the Documentation/Configure.help file etc. Easy solution: don't patch your kernel :-).

You see, MS doesn't have this problem. They give you one kernel, and you live with it.

Actually

[EverCode]

This is a good idea. Users could possibly even configure their kernel through a web browser, and CSS could be implemented to make the process pretty.

RDF might work better for this though, as Mozilla uses it. RDF is just a specification of XML, thought it used to not be, if I understand its history correctly, as it was an SGML application.

EC
"...we are moving toward a Web-centric stage and our dear PC will be one of

What's the problem?

[Rob Kaper]

I hardly see a big problem with the current setup..

• Most novice users will never ever compile their own kernel.
• For those of us who do, make oldconfig will do fine for a simple kernel upgrade with no hardware changes. When you do have hardware changes, is make menuconfig really such a pain?

I think that the configuration might need to be re-catagorized for simplicity and accessibility, but I doubt whether XML or another technique will be magic pixie dust.