Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!sdcsvax!John
From: jbn@glacier.stanford.edu (John B. Nagle)
Newsgroups: mod.os
Subject: Re: kernel servers vs. user servers.
Message-ID: <2480@sdcsvax.UCSD.EDU>
Date: Sat, 17-Jan-87 20:51:50 EST
Article-I.D.: sdcsvax.2480
Posted: Sat Jan 17 20:51:50 1987
Date-Received: Sun, 18-Jan-87 01:47:38 EST
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Stanford University
Lines: 62
Approved: mod-os@sdcsvax.uucp

--

      It's a sad commentary on the operating systems we use today that we have 
to build things into the kernel "to make them go fast".  Operating system
internals technology seems to have regressed since the days of Multics or
even the Michigan Terminal System.  Part of the problem is that the construction
of a layered operating system requires suitable hardware for efficient 
interaction between the layers.  Such hardware is not rare; most superminis
and mainframes have it; but most microprocessors do not, partly because this
issue cuts across the line between the processor and the memory management
hardware, and for most microprocessors, these are on separate chips, and the
chips are so designed that operation without an MMU is possible.
      Much of the portability of the UNIX kernel comes from its assumption 
that the hardware offers minimal support for structuring the operating system.	
We pay a price for this, in that as services are added to the system, the kernel
becomes huge.  And it never seems to have everything that everybody wants.
      What is needed is hardware support for interprocess and interdomain
communication.  Ideally, one should be able to do the following:

      - Write an application which offers a set of services callable by 
 	other programs, but has enough control over its own operation that
	it can protect the integrity of its own data structures.  Consider,		for example, a database system which offers services to other
	programs but should be able to maintain the integrity of the database
	in the face of foulups by the applications.

      - Call other applications with little if any more overhead than that
	required to call a subroutine in one's own space.

      - Find out from an application the identity of your caller in a
	protection sense.

      - Communicate with multiple callers from the same application.

      - Keep applications outside the system protection boundary, i.e.
        applications should not "run as root".

MULTICS, for example, provided all these capabilities.  To a lesser extent,
so does VMS.  UNIX does not.  This results in a need for terrible kludges
whenever a shared service is implemented, most of which only sort of work.
Some UNIX systems need special devices to make mail work.  Anyone who has ever
used the INGRES database has run into the "INGRES locking device".  And the
line printer spooling systems have always had locking problems.  Almost all of
the shared services in UNIX have a "set UID to root" program somewhere, and
thus are potential ways to breach security.

      Sockets and streams are steps in the right direction, as is the SUN RPC
mechanism.  What one really wants is something with the arm's length 
relationship of an RPC but the efficiency of an ordinary call.  This is not
impossible; it was achieved before 1970.  But one has to assume hardware 
support to get that efficiency.

      An interesting approach would be to define an RPC facility which, when
both entities were on the same machine and the machine sported suitable
hardware, turned into a more efficient direct call across a protection 
boundary.  With such an approach, one could have efficiency, protection,
distribution, and portability, although versions on machines without suitable
hardware would be slow.

						John Nagle


--