How to write a new Unix-like kernel

[Chip Salzenberg]

I have to agree with almost everything JFH and r$ have written about kernel
bloat and paging policies.  We all know that SunOS is the definition of
bloat, and that Plan 9 should take over the world.  (Oh, they didn't mention
Plan 9?  An oversight, I'm sure... :-))

However, let me comment on the speed of message passing...

According to jfh at rpp386.cactus.org (John F. Haugh II):
>In article <2046 at prune.bbn.com> rsalz at bbn.com (Rich Salz) writes:
>>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.

This statement may be true of Mach messages.  However, it's a matter of
priorities.  If the message designer likes speed, you'll get speed.

For example, I once worked on the design and implementation of a message-
based real-time OS for the Z-80.  Its message executive was implemented as a
array of function pointers.  Unassigned message ports pointed to a common
"you can't get there from here" routine, so minimal error checking was
needed.  It was _very_ fast.  (It had to be.)

A process that wanted to respond instantly could simply attach a subroutine
of its choice to the message port.  If immediate response wasn't required,
messages could be dropped in mailboxes for later perusal.  Mailboxes didn't
require special casing since they were code, too -- three bytes of "CALL",
followed by the message data.  Okay, it was a hack, but user code didn't
have to deal with it; at least it was a localized hack.

Before you say "what about multiprocessing," note that the back end of a
message port could very well be a network transmission function.

Now you may be asking, why is this in a Unix newsgroup?  The answer:  The
message system I just described served once as a practical base for a very
fast Mach-like kernel.  It could do so again.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip at ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton