Messages in this thread | | | Subject | Kernel functionality in user land | Date | Sat, 30 Mar 1996 14:36:52 +0100 (MET) | From | Matthias Sattler <> |
| |
Hiho
Now that we get the first programs that do kernel functionality in user land (think of arpd) it is the time that we talk about standardization of these features. My following thoughts are nothing but some starting points for the discussion.
1.) Can't the kernel code and the user-level code share much of its sources? I think of additional configuration options for the kernel like 'i' for internal (inside the kernel) and 'e' for external (user level process). If you then build the kernel, the external programs will be build along with it like the modules today. Then you have the advantage that there is only one codebase for all features and it comes with the kernel sources.
2.) Kerneld can start the user-level extensions when they are needed.
3.) Communication should always (no matter if internal or external) go over the kerneld message queue (Is the overhead bearable for internal communication? Is the kerneld message queue concept powerful enough? Can the kerneld message queue be used for inside-kernel communication?) This would give us much common code between internal and external features.
4.) Do we want linux to look like that? I do, but I want to hear your opinion too and in fact it is Linus who decides in the end.
5.) There are certainly some disadvantages too. I can think of one at the moment: Suddenly libc would have a direct influence on the kernel which makes things even more complicated.
Matthias
PS: This discussion won't influence linux-2.0.0 much, but I think its reults can be very useful for further development.
O .---------------. .___________. O /\/ . `. m_sattle@ ,' / \ +FAX . \/\ __..--- ' /\/ | `._________,' | (___)/ * * \(___) \/ \ ` ---..__ ""---__ \/`. | informatik. | / | \ +49 (0)6333 ,'\/ __---"" `.. / | .uni-kl.de | | `...' | -65079 \ ...' `---------------' `._____.'
--> Don't take life too seriously -- you'll never get out of it alive. <--
| |