Paper evaluations...

John Michael U. Datuin (jdatuin@san.rr.com)
Tue, 18 Apr 2000 07:52:52 -0700

The Pilot paper mainly discusses the various features of this single-user,
single-language (based on the Mesa language) OS. The features discussed
include the layout of its virtual memory structure, file system, streams,
communications, support of the Mesa language, and implementation. I thought
this paper was fairly straightforward UNTIL reaching section 3, the implementation,
when it became very difficult to read because of all the details the authors
introduced.
I think the key point in the Pilot paper is that Pilot was designed to provide
features that are easy and flexible to use, though lacking in robust protection
and resource allocation, yet extensible by having high level programs build upon
these basic features, which the authors explain are public "interfaces" of Pilot.
Pilot borrows a lot of ideas from previous systems, e.g., the use of capabilities
from Hydra in the implementation of its file and volume interfaces. In its virtual
memory architecture, Pilot uses a linear design which the authors state are
structured into this concept of "spaces" (basically a collection of sets of pages).
The authors believe that the use of spaces is unique in that subspaces can be
created from spaces, forming some tree hierarchy of the whole virtual memory
that is easily mapped and maintained. Pilot introduces the stream concept
with its notion of transducers and filters, with the authors claim is very
similar to the pipe and filter features of Unix.
The communications section was very interesting. The authors explain
that Pilot contains network communication features, but I was surprised
when it appears they introduced the concept of the client-server model. I
wonder if the idea of the client-server model was first introduced here.
As I stated earlier, the rest of the paper, starting with the implementation,
just lost me from there, except when the authors explained the file system
robustness (with their scavenger idea), communication implementation (where
they introduced the router??? concept), and finally with their conclusion.
Overall, the paper was fairly interesting in seeing a non-multiprogramming
system approach.

I thought the paper on the Opal system was very difficult to read and
comprehend, even with the large font size and various pictures sprinkled
about. The only things I could get out of this paper was that Opal was
based on the Mach microkernel, was a single address space OS, and
took advantage of the wide-address architecture of new 64-bit address
machines.
The main idea behind their sharing and protection scheme was in
their notions that addresses in Opal are context-independent, so that
programs could access the same piece of data; this single global virtual
address space was shared by everything in the system. And that protection
is provided by taking advantage of what the authors call "judicious" address
space that's provided with these wide-address machines.
I thought the authors were being lazy in that, even though the address
space using 64 bits is extremely huge, using the address space to map
processes and data without ever re-using addresses is extremely
wasteful and overly dependent on this wide-address approach.
I believe one of the key ideas the authors were trying to emphasize
in Opal was in the use of protected domains, which they say is the
execution context for threads, for protection. These protected domains
allowed specific access to segments of memory and are named by a unique
256-bit ID called a capability (similar to Hydra's capabilities???), with name
service supports provided with ACLs (similar to Multics???). And with
"portals", a thread executing in a protected domain can enter another
protected domain seems similar to "gates" which we read about earlier.
Overall, this was a tough paper to read and difficult to enjoy (unlike
the Multics and Unix papers, which were so very familiar).