Fw: Some very thought-provoking ideas about OS architecture.

shapj@us.ibm.com shapj@us.ibm.com
Sun, 20 Jun 1999 16:54:42 -0400


[ ** Readers of cap-talk see the note at the bottom for how to see the first 10
messages in this thread ** ]

Boy am I glad that I checked that email today rather than next week... :-)

PLEASE, if you reply to this, make sure that you reply to both mailing lists!

Eric: thanks for the kind words.

Alan: believe it or not, I agree with many of your thoughts about indexing and
consistency. It doesn't follow from them that EROS is a bad design point.  You
appear to have made some assumptions about the EROS design that I'll try to
correct.  If I have misunderstood you, apologies in advance.

I will be sending out two notes.  One on motivation/background for EROS, the
other specific to the persistence discussion.  The second will take a while to
write, so they won't come back to back.

** BACKGROUND:

In spite of Eric's kind words, I cannot take all (or even most) of the credit
for the EROS architecture.  The architecture goes back to the early 1980's.  It
originally deployed under the name KeyKOS, and was used in credit card,
transaction processing, and communication applications.  I had no association
with KeyKOS beyond knowing some of the people involved.  The company that owned
it has for all practical purposes disappeared, and with the blessings of the
original architects (Norm Hardy, Charlie Landau, and Bill Frantz), I set out to
do a clean-room reimplementation.  This eventually turned into my PhD thesis,
and into a working (and fast) implementation.  There has been some migration in
the architecture over the years.

The EROS website includes extensive writings, and can be found at
http://www.eros-os.org.

For the truly sado-massochistic (or merely curious), a complete archive of the
architecture discussions leading to EROS can be found at

     http://www.eros-os.org/~majordomo

under the eros-arch list.

EROS is open-sourced under Mozilla, though I retain proprietary right to use on
all changes.  [There are good reasons for this, and if you wish to discuss them
please send mail to me rather than to the list -- it doesn't belong here.]

** MOTIVATION

The original ideas that motivated KeyKOS (and subsequently EROS) came out of a
simple question: how do you build an OS in which mutually adversarial users can
operate in safety, but can also collaborate in ways that they can control.  The
original context was Tymnet, one of the earliest time sharing services.  In the
course of a series of acquisitions and divestitures, this OS came to be owned by
Key Logic, Inc., and came to be known as KeyKOS.  Many papers and some of the
original design documentation can be found at

     http://www.cis.upenn.edu/~KeyKOS


Working independently, the Agoric Open Systems community was pushing in the same
directions (see http://www.agorics.com/agorics/agorpapers.html, in particular
the first paper: "Markets and Computation: Agorics Open Systems"), and the
market-based computation community was also going here (see Nick Szabo's page at
http://www.best.com/~szabo, in particular "Formalizing and Securing
Relationships on Public Networks ").  All of them, in one fashion or another,
came to the conclusion that these sorts of underpinnings were necessary.  The
basic requirements, first stated (as far as I know) in the "Markets and
Computation paper..." is that

     ... systems capable of supporting open computation all share
     support for the encapsulation and communication of information
     and access. Communication of information is fundamental to
     computation that involves more than a single object. Encapsulation
     of information involves separating internal state and implementation
     from external behavior, preventing one object from examining or
     tampering with the contents of another.

I'ld add to this that communication and encapsulation of resources is also
necessary, and that mandatory access controls may be politically essential, in
spite of the fact that they are in principal not enforceable [If you care to
argue that, PLEASE alter the subject line, and be advised before you engage that
it's a formally proven result].

The desire to build electronic commerce frameworks is what prompted me to work
on EROS.  Capability-based foundations appear to be essential if the
requirements stated are to be met.

** STATUS

EROS is running on Pentium-class processors.  Charlie Landau has graciously
agreed to take on coordination of the archive and ongoing open-source effort.
One of my tasks for today is to get a machine ready to ship to him.  The system
is quite fast, but has minimal applications at this point.  The next two
critical steps are getting the kernel converted from C++ to C and then getting a
TCP/IP stack up and running.

** For cap-talk readers:

For those of you on cap-talk who are coming in on the middle, I have added the
thread of discussion to date to the cap-talk archive by hand.  If you wish to
catch up, please point your browser at:

     http://www.eros-os.org/~majordomo/cap-talk/index.html

And take a look at the "Some very thought-provoking ideas about OS architecture.
" thread.


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