Messages in this thread | | | From | shapj@us ... | Date | Sun, 20 Jun 1999 16:54:42 -0400 | Subject | Re: Fw: Some very thought-provoking ideas about OS architecture. |
| |
[ ** 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
- 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/
| |