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?"
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 :)
--
I think there is a world market for maybe five personal web logs.
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!
(darren)
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!
(darren)
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.
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
EverCode
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.