I'll select "It will increase system performance", in a
specific context: a dedicated Web/FTP/NSF/DNS server. In the
hypothetical dedicated Web server process, for instance, I'll run
special code whose purpose is to grab HTML data from storage and shove
it out the net as efficiently as possible. In this instance,
maintaining campatibility with the existing Unix networking API is not
terribly important, and may be sacrificed in the interests of overall
performance.
You're making a lot of assumptions that doing Unix networking in the
user-space will actually be faster than doing it in the kernel. The
approach of doing zero-copy disk reads, and zero-copy network writes
(assuming the network card can do the IP checksum for you) can result in
fairly studly transfer rates, as SGI has demonstrated. (And there's
been some consideration as to whether or not we could implement similar
optimizations for the Linux kernel; it would only apply for certain
hardware devices and if the user buffer were page aligned, but if those
conditions were met, the resulting code would really fly.)
Of course, we're still paying the cost of two context switches; but
that's going to be in the noise, I suspect. If you want to get rid of
that, then obviously the fatest way to do things is to chuck the OS
altogether and just write an assembly language program that reads from
the disk directly, and writes to the network directly. Never mind about
device independence, and abstraction, and all of the other nice things
that an operating system provides.....
The real challenge, of course, is how do you provide all of the benefits
and abstractions that an OS provides at the smallest possible cost.
The argument that Linus raises is that it's not fair for a microkernel
to fudge this trade-off by radically reducing the benefits provided by
its "kernel", and then compare the result to a full "real-life" kernel.
That being said, I suspect there's a lot we can do to be clever, such as
the zero-copy I/O.
- Ted