What SHOULD go in the kernel

[John F. Haugh II]

In article <47040 at bbn.COM> pplacewa at antares.bbn.com (Paul W. Placeway) writes:
>First off, kernels are generally harder to debug than user programs,
>so the less stuff you add there the better off you will be.  Also,
>most kernels won't do VM on themselves (for several _good_ reasons
>:-) ), so any extra code you put in the kernel will be sitting there
>taking up space even if you don't need it right now.

I don't have trouble with the first part, but discouraging paging
the kernel is kinda wasteful the way kernels keep bloating.

The primary restriction against a paging kernel is keeping the
paging code from being paged ;-).  After that, satisfying real-time
constraints, etc. will yield a collection of pages which must
be locked in memory as well.  What should be left in the list
of locked pages should only be lower halves of device drivers,
the VM manager, the pager, and the global data required by those.

Massive tables, seldom used device drivers, and one-time 
initialization code should all be candidates for the pager.
I paid for the memory, and damnit, I want to use it.

>On the other hand, it's much harder to do real-time-ish things in a
>user program than in the kernel on most UNIXes.

Granted.  However, much of what is in a UNIX kernel has no
real time requirements and should be paged out when not required.

Dynamically loadable device drivers are wonderful.  When can
we see dynamically unloadable device drivers ;-)
-- 
John F. Haugh II                        +-Things you didn't want to know:------
VoiceNet: (512) 832-8832   Data: -8835  | The real meaning of MACH is ...
InterNet: jfh at rpp386.cactus.org         |    ... Messages Are Crufty Hacks.
UUCPNet:  {texbell|bigtex}!rpp386!jfh   +--<><--<><--<><--<><--<><--<><--<><---