Re: Some very thought-provoking ideas about OS architecture. shapj@us.ibm.com
Mon, 21 Jun 1999 13:04:42 -0400 

> Linus Torvalds wrote:

> > In short: message passing as the fundamental operation of the OS is just
> > an excercise in computer science masturbation. It may feel good, but
> > you don't actually get anything DONE. Nobody has ever shown that it
> > made sense in the real world. It's basically just much simpler and
> > saner to have a function call interface, and for operations that are
> > non-local it gets transparently _promoted_ to a message. There's no
> > reason why it should be considered to be a message when it starts out.

With due libations to the Gods here, Linus is mistaken on all counts.

Moving a message from hither to yon *does* accomplish something: it moves a unit of work from one protection/encapsulation domain to another. This may not be necessary in your application, but it is vitally important in some. The claim that nobody has ever shown benefit is also inaccurate. A considerable amount of open literature on fault tolerant software exists to support the value of message passing in certain applications. Consider in particular all of the research reports out of Tandem. Also, note that all of the operating systems whose software MTBF exceeds 1 yr make heavy use of protection domains.

More important, from my perspective, is that the comment about procedure calls confuses the API for the semantics. Let's do an example. Consider the UNIX read call read(fd, buf, sz) [I may have gotten the arg order wrong. It doesn't matter]. Assume for a moment that we are implementing a single machine system.

From an implementation perspective, there is absolutely NO performance difference between the implementation of

read(fd,buf,sz)
and

fd->CALL(OP_READ,buf,sz)

The order of demultiplexing changes -- the read() call does the operation first and the descriptor second, while the CALL does the descriptor type first and the operation second, but precisely the same information is passed across the user/supervisor boundary, and several implementations exist to show that they are equivalently efficient.

Given this, there are compelling arguments for the second API:

  1. By changing the order of demultiplexing, it offers the option of remoting at a later time.
  2. It allows objects to implement non-identical system call interfaces. This is easily abused, but sometimes extremely valuable.
  3. It offers the option of depriving the program of the ability to perform I/O calls by ensuring that it has no objects that support I/O.

So: even if you think that message passing is not the way you wish to implement things, object based APIs offer greater flexibility of implementation, and this is generally a good thing.

Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595