What SHOULD go in the kernel

[Peter da Silva]

The distinction between whether something goes in the kernel or runs as
a seperate process comes down to two considerations:

	1. Protection: does this thing have to violate normal process
		protection mechanisms?
	2. Performance: this comes down in turn to two considerations:
		a. Realtime activities: for example, doing a streaming tape
			driver is a pretty hard realtime problem.
		b. Throughput considerations: excessive context switches
			lowering system performance to an unacceptable
			amount.

As time goes on, the protection mechanisms get more complex and capable.
Shared memory, PTYs, and so on allow stuff that used to live in the kernel
(console drivers) to perform their jobs withing the protection mechanism.
Look at XTERM, for example.

In Mach, with user pagers and the like, this requirement is about dead.

As processors become faster, throughput questions become less meaningful.
Once upon a time canonical tty processing was one of those things that had
to be in the kernel. Again, XTERM is an example of an activity that has
moved outside the kernel... because processors can afford it as well because
PTYs exist.

The final barrier is realtime activities. UNIX is not a realtime system. To
some extent this can be glossed over as non-real-time performance becomes
fast enough. Still, real realtime support is needed before the kernel can
be completely flushed of alien material... a 20 megaherz 80386 is not fast
enough to handle XON/XOFF processing in a user process (a problem I'm currently
trying to deal with), let alone hard problems like tape drives, disk drives,
and networks.

One of these days, though...
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter at ficc.uu.net, +1 713 274 5180. Fun: peter at sugar.hackercorp.com. `-_-'
"I feared that the committee would decide to go with their previous        'U`
 decision unless I credibly pulled a full tantrum." -- dmr at alice.UUCP