Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!brutus.cs.uiuc.edu!ginosko!rex!ames!vsi1!altos!altos86!dtynan
From: dtynan@altos86.Altos.COM (Dermot Tynan)
Newsgroups: comp.unix.wizards
Subject: Re: What SHOULD go in the kernel
Message-ID: <3718@altos86.Altos.COM>
Date: 27 Oct 89 02:44:21 GMT
References: <2186@ektools.UUCP> <47040@bbn.COM> <17166@rpp386.cactus.org>
Distribution: na
Organization: Altos Computer Systems, San Jose, CA
Lines: 25

In article <17166@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F. Haugh II) writes:
> The primary restriction against a paging kernel is keeping the
> paging code from being paged ;-).
> [...] seldom used device drivers, [...] should all be candidates for
> the pager.

This is not entirely accurate.
Another reason for not paging the kernel, is instruction restart within a
device driver.  A classic example is a UART with a FIFO.  Allowing
instruction restart after a page-fault, when the driver is reading from the
UART, and writing to (pageable) memory will create havoc.  Intel products
are insulated from this, because they have a separate I/O bus, which means
that I/O can only be done to an on-chip register.  However, memory-mapped
I/O will fail horribly.
It would probably make a big difference, if people who had kernel link-kits,
would remove all the junk they didn't need.  On top of that, if marketing
types would take a big deep breath, and decide on ONE topology, the kernel
wouldn't need to be so big.  I mean, why does S5R4 (or 4.4BSD for that
matter) need TCP/IP *and* ISO, RFS *and* NFS, etc, etc.
						- Der
-- 
	dtynan@altos86.Altos.COM		(408) 946-6700 x4237
	Dermot Tynan,  Altos Computer Systems,  San Jose, CA   95134

    "Far and few, far and few, are the lands where the Jumblies live..."