Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <31967@bu-cs.BU.EDU>
Date: 29 May 89 21:26:01 GMT
References: <106326@sun.Eng.Sun.COM> <31756@bu-cs.BU.EDU> <8565@chinet.chi.il.us> <10336@smoke.BRL.MIL> <280@ecijmm.UUCP>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: comp.unix.wizards
Organization: Software Tool & Die
Lines: 30

In article <280@ecijmm.UUCP> jmm@ecijmm.UUCP (John Macdonald) writes:
|In article <10336@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
|This method originated with the (Waterloo) Thoth Operating System [1],
|and has since been used and extended in a number of other systems (perhaps
|most notably the Stanford V system[2] [and maybe Mach too, but I don't know
|about that]).  This method uses small fixed size messages sent between
|processes using primitives send, receive, and reply.  The sender blocks
|until the receiver accepts the message AND replies to it.
[...]
|This mechanism allows for a huge amount of non-kernel implementation of
|system capabilities [...]
|using a single mechanism in a rather elegant clean fashion.

MINIX, a small Version 7 implementation of UNIX, uses a
message-passing kernel as well, and has processes handle just about
everything except scheduling.  Given that MINIX is a teaching tool,
we may see more of this showing up (see _Operating Systems:  Design
and Implementation_, A. Tanenbaum).  It certainly has an elegant
design, and since you get to futz with source, MINIX is an excellent
system for teaching.

There are problems with message-passing; it's usually a bottleneck,
creates overhead on every call (even those which you would like to
have almost no overhead), and is often difficult to move to
multiple-processor systems.  All of these problems can be corrected,
but you screw up the elegance of the system.

jim frost
software tool & die
madd@bu-it.bu.edu