Re: Appications in kernelspace (was:Tux in main kernel tree?)

[Anders Peter Fugmann <afu@fugmann.dhs.org>]

Michael Rothwell wrote:
> From: "John Stoffel" <stoffel@casc.com>
> 
>>Or maybe we should include kDNS and kftpd as well now?
 >
> Or even (laugh), an NFS server...
> 
Before I begin, I would like to say that I have never tried khttpd or TUX, and
I do not tknow how they are implemented. It has been postulated (and I beleive that)
that tux and khttpd in kernel space outperforms the userspace equivelent.

In my oppinion, application level protocols should not exist in the kernel-space.
Whenever a functionality is implementented in the kernel, people tends to optimizing generic
tings in the kernel for this functionality (at the cost of genericness).
If we take this thought to the extreme, I can see lots of different kernels in the future with
names like: 3.8.23-http, 3.8.22-nfsd, 3.8.56-IE7 etc, and changlogs like:
- backport VM-IE7 changes from 3.8.56-IE7 to 3.8.23-http.

What we end up with is unmaintainable kernel-code, since focus is removed from the generic kernel
to specific kernels.

Alternative:
Since TUX and khttpd does gain extra performance by running in kernel space,
I think that the problem is clear.

	Userspace programs have no change of performing near the harware/theoretic
	optimum.

Lets fix that. The kernel should not be optimized
for a single program, but allow any program to take advantage of some interface.
NFSd might belong to userspace (I dont know - really), but if its significantly faster in kernel
then we need some changes in the kernel API, to allow same speed in userspace if nfsd belongs there.

Conclusion:
Khttpd et. al. does not belong to the kernel.
Adding applications to the kernel moves focus from generic correct implementations to specific optimizations.
Effort should be made to find out why httpd et. al. is faster, and what can be done _genericly_ to allow
near same performance in userspace.

Hope that this starts some thoughts.
Anders Fugmann