Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: What SHOULD go in the kernel
Message-ID: <17200@rpp386.cactus.org>
Date: 27 Oct 89 14:54:09 GMT
References: <2186@ektools.UUCP> <47040@bbn.COM> <17166@rpp386.cactus.org> <3718@altos86.Altos.COM>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Distribution: na
Organization: River Parishes Programming, Austin TX
Lines: 45

In article <3718@altos86.Altos.COM> dtynan@altos86.Altos.COM (Dermot Tynan) writes:
>This is not entirely accurate.

No, because you didn't bring all of the context with the quotation.
An early response stated that interrupt handler lower halves needed
to be locked in memory.

>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.

This may or may not be true depending on the CPU and how instruction
restart is handled.  If no memory cycles are duplicated on restart
[ i.e., a read cycle early in the instruction will not be re-executed
during page fault processing ] you probably won't lose.  Not all CPUs
get this wrong!  It is conceivable that enough state information is
stacked on the exception to permit the instruction to resume from the
same state [ this requires dumping gobs of internal state onto the
stack, including microcode registers, etc ].

The difference is whether the instruction is re-run, or re-started.
I've never written page fault handling code for the MC68020, but I
understand it dumps 40 or 50 words of information on the stack and
after the return from the page fault handler picks up at the same
exact microinstruction [ more or less no doubt ].  The implication of
this being that no steps are repeated [ and you can run all of your
programs in one page of memory ;-) ]

>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.

Yes.  Better still is dynamic configuration at boot time with a
minimal configuration set up by default during installation.
-- 
John F. Haugh II                        +-Things you didn't want to know:------
VoiceNet: (512) 832-8832   Data: -8835  | The real meaning of EMACS is ...
InterNet: jfh@rpp386.cactus.org         |   ... EMACS makes a computer slow.
UUCPNet:  {texbell|bigtex}!rpp386!jfh   +--<><--<><--<><--<><--<><--<><--<><---