Messages in this thread | | | Date | Sun, 22 Oct 2000 12:17:24 -0400 | From | Jason Hihn <> | Subject | Idea for new kernel configurator |
| |
First let me introduce myself and explain where I am coming from. I'm a just out of college software engineer, I've been using Linux since about 1994. I hope this is the right place to air this idea. I've never dabbled in the kernel other than applying some patches. Recently at work I've had to develop an application which would allow a user to configure a device, even if that device was invented after the application was written. This is done extracting information (an XML file) out of the device which allows the software to create an interface for configuring the device... and that's where my idea comes from. (Quick, someone document this before it is patented!)
If the linux kernel was represented by XML objects in documents, then the same idea as above could be applied and extended. The user interface could be 2 windows, one 'in-the-kernel' pool and one 'not-in-the-kernel' pool. (I am thinking either icons, like folders, or trees) to add something into the kernel, just drag and drop, to take something out drag and drop. To configure parameters right click and select stuff off of a context menu, or pop up a property page.
The advantages of this are: 1) If carefully abstracted, the same software could be used not only for the kernel but other software things as well (PHP (--with-mysql, --with-postgres would be drag and dropable features), etc....) Which would provide a familiar, consistent interface
2) My mother could configure and build the kernel with very little instruction (She'd probably have to phone-a-friend though)
3) It's conceptually ideal. In the kernel, out of the kernel. Property sheets to adjust params, etc.
4) Installing patches could be done as well. Either another Patches window, or the functionality could be enabled at the proper software module.
5) The application [sh|c]ould handle the build/install process and give a status bar.
6) It allows me to contribute something and give back to the community that has given me so much.
7) Even if the kernel people do not decide to XML describe the kernel, it would be possible by a 3rd party to apply the XML documents to the tree and allow people to use such a tool.
The down sides are: (few) 1) Graphical display required.
2) Patch contributors now need to make an additional XML file
3) how are overlapping patches handle?
As a final note, I regret to say I don't have time to actually code such a project at this time, but I'd like to help as much as I can.
I submit this idea for your approval and critique (Has it already been done?? - not to my knowledge)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |