How to write a new Unix-like kernel

[John F. Haugh II]

In article <2046 at prune.bbn.com> rsalz at bbn.com (Rich Salz) writes:
>In <17166 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
>> ... discouraging paging
>> the kernel is kinda wasteful the way kernels keep bloating.
>
>Take this sentence backwards, and it becomes a feature:  since the kernel
>can't page, you can't puff lots of stuff into it.  This has forced a
>certain economy of design (phrase lifted from one of the Unix papers, read
>them all and find out which one -- it'll be good for you) that has
>resulted in the initial success of Unix lo these many years ago.

Don't shoot the messenger!  I haven't encouraged kernel bloat, I'm just
reporting the facts.  I've frequently professed my admiration for the
7th Edition kernel in this newsgroup.  And I have read the UNIX papers,
including the one which says that UNIX really isn't an operating system.

>I don't think this bloat is necessary, and as Dick Dunn has implied in
><1989Oct19.220105.10185 at ico.isc.com>, if you make it possible to have the
>kernel page, then all you do is make it possible to have every
>semi-competent bozo put everything they want in the kernel.  Goodbye
>tasteful and understandable set of features, hello [VM][MV]S.

I agree.  However, if we are going to be adding features to a minimal
kernel [ such as networking, graphics, security ] we are either going to
have to cleverly redefine what exactly is =the= kernel or find more
efficient methods of managing the memory we are consuming.

In my mind it is the customer who is driving this software obesity.
You can either argue that Sun is successful because the customers
like the software features and buy more Sun's, or you can argue the
Sun programmers keep adding features because the sales staff keeps
doing a better job of fooling Sun's customers.  I'd love to see an
analysis of SunOS size versus Sun annual sales.  If you care to point
out that every company is growing their OS, I might point out that the
ones that didn't stay on the leading edge of creeping featurism are
now, in the main, out of business.

Besides, who says VMS or MVS or VM/SP are not useful operating systems?
If the question is "How do I put 2000 users on one machine?", my answer
is probably going to be MVS.  The question may be kinda stupid and
anyone who really wants a DASD farm deserves MVS, but it is a solution.

>On the other hand, if you let the kernel page, then you can take all the
>stuff that doesn't page and call that the "real" kernel.  As long as it's
>paging the other parts, put them in user space, and give users the
>opportunity to put their own code in for their programs.

Here I disagree.  Almost everything in a kernel is pagable.  If you
remove everything that can be paged or replaced you get CP.  Taking
a module out of the kernel and cleverly calling it the "real" kernel will
only populate the memory with "user" processes which are now paging.

The user -should- be able to select which file system they want bound
into their kernel.  If you want big and fat, the Berkeley Fast File
System is available.  If you want small and stupid, RT-11 comes to
mind ;-)

Create a standard interface model and code two or three file systems
to fit that model.  Then do the same with network interfaces, graphics
interfaces, etc.  I really should be able to have X in the kernel or
not.  I may need 16MB just to boot, but I should be able to do it.

>I don't expect someone whose .signature says that Mach stands for
>messages are crufty hacks will like this design very much, but I'd
>rather avoid bloat, myself.  (Do I have to say that this is intended
>to be a mild tweak and not one of the famous "Usenet ad hom.
>attacks"?)

Probably ;-)  Do you like the new .signature better?

I feel strongly against message passing schemes for the same reason
I'm not totally sold on lightweight kernel processes.  jsr's are cheaper
than messages or context switches.  You haven't guaranteed my MACH
processes aren't going to be paged out, so you've gained nothing more
than this warm fuzzy feeling that MACH's 55KLOC kernel is more
understandable than SunOS 4.0 or AT&T's latest overweight offering.

In fact, I'll even argue MACH is dangerous because it now gives
everyone an entirely new level to populate with crap.  I feel very
confident in stating that MACH will be big and crufty in even less
time than it took UNIX.  Everyone is so much better at adding cruft.
-- 
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 at rpp386.cactus.org         |   ... EMACS makes a computer slow.
UUCPNet:  {texbell|bigtex}!rpp386!jfh   +--<><--<><--<><--<><--<><--<><--<><---