What SHOULD go in the kernel

[Chris Torek]

In article <2186 at ektools.UUCP> jwr at ektools.UUCP (Jim Reid) writes:
>Is there a rule of thumb of what should and should not be put in the
>kernel?  To be more specific, is it better to make a device driver 
>'lean-and-mean' or sophisticated, so that the user interface (the read(),
>write(), ioctl()) is simpler?

There are two conflicting goals in device drivers, and right now the
standard Unix kernels (BSD and [as far as I know] Sys5) do not always
help.

The first goal is indeed the `lean-and-mean' approach.  By writing only
what is absolutely necessary for reliability, you can get the driver
debugged quickly, and you do not wire bad assumptions into it.  You
can then tune it for performance, if necessary and appropriate.

The second goal is device independence.  If you wrote a DH driver so
that its read() and write() routines simply did I/O, and user code
had to do things like

	int lp = 024;	/* 8 bits, even parity */
	ioctl(fd, DHIOC_SET_LINE_PARAM_REGISTER, &lp);

it would work, and it would make the driver simpler.  But you would
discover that you needed many different versions of `stty' in order to
run on DHs, DZs, DMFs, DMZs, DHUs, DHVs, etc.  Instead of being quite
so `lean', it is better to establish a common abstraction, such as
a `tty device', and make the same (abstracted) ioctls work on each
device to the best of that device's ability.

Current Unix kernels offer a limited set of abstractions, and limited
support for each.  There are `block' (file system) devices and
`character' (other) devices, and these are further divided into `disk'
and `tape' block devices, and `tty' and `other' character devices.
(4BSD also has, to a limited extent, `tape' and `disk' devices, and it
has `network' devices that are neither block nor character [which is
another problem entirely].  Other kernels may have other classes of
character devices, e.g., Sun's `frame buffer' devices.)

I have rattling about in my head an improved system for grouping
devices based on abstractions, and if I ever sit down and write it, it
may appear in a future BSD release.  (But here I am reading news
instead of getting work done.)

Chris
-- 
`They were supposed to be green.'
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris