Kernel Configuration via XML? 13
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 (Score:1)
Re:KML? (Score:1)
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? (Score:1)
Just a thought...
Sean
Yes! (Score:1)
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
Re:Why XML? (Score:1)
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
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 (Score:1)
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
XSLT: its not just for serving to old browsers. Use it. [apache.org]
That's what we have (Score:1)
Re:Why XML? (Score:2)
--
KML? (Score:2)
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? (Score:2)
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? (Score:2)
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 (Score:3)
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? (Score:4)
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.