Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.unix.wizards
Subject: Re: What SHOULD go in the kernel
Keywords: device drivers
Message-ID: <12315@ulysses.homer.nj.att.com>
Date: 23 Oct 89 01:38:34 GMT
References: <2186@ektools.UUCP> <20230@mimsy.umd.edu> <14163@well.UUCP>
Distribution: na
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 22

In article <14163@well.UUCP>, nagle@well.UUCP (John Nagle) writes:
> 
>        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...

In fact, VM/370 does a rather poor job at it.  More precisely, given the
System/370 I/O architecture -- which was not designed for virtualization,
or even (originally) for virtual memory -- analyzing the channel programs
for safety and correctness, and constructing the proper emulation is
hard and expensive.  There have been microcode assists added over the
years to aid VM, but I'm not sure if any of them help with arbitrary
I/O requests.  Fielding the interrupts is even harder.

This doesn't invalidate the basic Nagle's basic point, but allowing
user-level programs raw access to I/O space is quite complex architecturally.