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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/