Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!well!nagle
From: nagle@well.UUCP (John Nagle)
Newsgroups: comp.unix.wizards
Subject: Re: What SHOULD go in the kernel
Keywords: device drivers
Message-ID: <14163@well.UUCP>
Date: 19 Oct 89 16:20:34 GMT
References: <2186@ektools.UUCP> <20230@mimsy.umd.edu>
Reply-To: nagle@well.UUCP (John Nagle)
Distribution: na
Lines: 29


       One could argue that device drivers don't belong in the kernel
at all.  With reasonable hardware support, no loss in protection is
implied by this.   The operating system must provide the mechanisms
to map one peripheral's I/O space into the space of the driver process,
and the memory management hardware must mediate accesses initiated by
the device itself (whether "DMA", "bus master operation", or "channel
program execution").

       Systems with these capabilities include IBM mainframes under VM, and
Apollo machines under Domain when equipped with the add-on box for user
supported peripherals.

       One also needs something like named pipes for communication between
applications and device drivers.  This intercommunication mechanism must
include 1) bidirectional I/O 2) out-of-band control messages ("IOCTLs"),
3) the capability of one end to verify the identity and security status
of the other end, and 4) the ability of one end to detect termination
of the other end.

       With capabilities like this, you can kick the device drivers,
terminal handling, networking, and file system out of the kernel.

       Unfortunately, UNIX isn't designed to work this way, and the
success of UNIX has resulted in the decline of hardware support for
this sort of thing.  The result is the bloated kernels of today.

					John Nagle
h