Xref: utzoo comp.unix.wizards:19016 comp.os.minix:7731
Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg
From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.unix.wizards,comp.os.minix
Subject: Re: How to write a new Unix-like kernel
Message-ID: <PCG.89Oct29140916@rupert.cs.aber.ac.uk>
Date: 29 Oct 89 14:09:16 GMT
References: <17166@rpp386.cactus.org> <1989Oct19.220105.10185@ico.isc.com>
	<2046@prune.bbn.com> <17175@rpp386.cactus.org>
	<2546462F.5156@ateng.com>
Sender: pcg@aber-cs.UUCP
Organization: Coleg Prifysgol Cymru
Lines: 59
In-reply-to: chip@ateng.com's message of 25 Oct 89 23:47:58 GMT

In article <2546462F.5156@ateng.com> chip@ateng.com (Chip Salzenberg) writes:

   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.

MUSS (from Manchester University) has a similar scheme; you can
send entire virtual memory segments from one process to another,
and this only passes the handle to the segment's paging tables
from the source process to the target process.

The filesystem will, when you want to open a file, send you a
pointer to paging tables that map the disk pages of the
segment/file; as you use them they are faulted in. When two
process ask to open the same file, they are given paging tables
to the same physical pages, thus creating shared memory. On the
other hand, sending a message does not require any core-to-core
copy, nor copy-on-write and its complexities, only a pure process
switch.

Devices are seen as processes, so for example to print a file you
just send the handle to its paging tables to the printer process.
A tty is seen as a process; when you type a line it is wrapped in
a segment and sent to the process you have indicated to the tty
driver via an escape (yes, there is provision for efficient
handling of very small segment, less than a page worth). Each
process by default replies to the sender of the latest segment.

You can thus have multiple ttys interacting with a process,
multiple processes waiting on a tty (doing entirely away with the
ridiculous, hackery job control idea from Bill Joy), the
processes need not be on the same machine as the tty, the
filesystem can be on another machine, the printer on another
still (process names are network wide).

The entire kernel, which is substantially more powerful than the
Unix kernel, is a few dozen kilobytes on a VAX; this because a
lot of things are not necessary, from the buffer cache to file
handling to job control, as they are subsumed in the virtual
memory plus segment passing mechanism.

MUSS ran on a large cluster of very different machines (a home
made supercomputer, a mainframe, some minis, a few micros)
connected by something akin to a bus local area network, in the
early seventies, with remote and transparent login, filesystem,
print service, IPC...
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk