Even though most of you have read my mail on the first of april (I've sent
it on sat. march the 30th), it is definately not meant as an april fools
joke (is this the right word?). I'm sure that arpd is only the first of a
series of programs that do operating system functionality as a normal
user-level process (with realtime mechanisms if necessary). If we discuss
the design of those programs now we'll avoid much confusion (everybody does
things a bit differently, because there is no standard way to do it) and
suboptimal implementations. For that reason I quote my last mail and hope
to get a better response now.
Matthias
>
> 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. <--