From dfk@cs.dartmouth.edu Mon Apr 25 11:46:24 1994 Date: Mon, 13 Dec 93 15:24:30 -0500 From: dfk@cs.dartmouth.edu (David Kotz) To: sasos%cs@Dartmouth.EDU Subject: New mailing list on Single-Address-Space Operating Systems (SASOS) Status: RO After a discussion with several people at SOSP, we decided that it would be helpful to have an email-list of people interested in Single-Address-Space Operating Systems (SASOS; sometimes known as 64-bit operating systems, flat address spaces, wide address spaces, etc). We have created a mailing list for interested parties, including many research groups that are actively building SASOS systems. We initialized the list (see below) with the names of people we met at SOSP, plus some others we invited. Please forward this message to anyone else you think might be interested. To send mail to the list, mail to sasos@cs.dartmouth.edu To join or get off the mail to the list, mail to sasos-request@cs.dartmouth.edu We have also created an ftp archive on cs.dartmouth.edu that we hope to fill with relevant information. To start, we have two files: list the members of the electronic mailing list (below) sasos.bib a bibliography of related papers [Please be patient with cs.dartmouth.edu over the next few weeks; we've just moved our entire department to a new building and at the moment that machine is quite slow.] Contributions to the directory are welcome. Please send them to one of us. We are particularly interested in getting bib entries for any papers you find that are missing from the bibliography (we'll update it from time to time), and a one-paragraph ASCII description of your research project. David Kotz Assistant Professor Mathematics and Computer Science Dartmouth College 6211 Sudikoff Laboratory, Room 116 Hanover, NH 03755-3510 USA email: David.Kotz@Dartmouth.edu 603-646-1439 Single-Address-Space Operating Systems As of 12/13/93 David Kotz (list maintainer) John Carter Jeff Chase (Opal) Preston Crow Paulo Ferreira (SOR) Ben Gamsa (NUMAchine/Tornado) Kaushik Ghosh (KTK) Jon Inouye (Chorus) Robert Klinkhammer Ram Kordale Sacha Krakowiak R. Andrew McCallum Donald Miller T Okamoto John Rosenberg (MONADS) Stephen Russell (MUNGI) Ashley Saulsbury (Angel) Michael Scott Bart Sears (HP PA-RISC) Tim Wilkinson et al (Angel) From dfk@wildcat.dartmouth.edu Mon Apr 25 11:46:27 1994 Path: dartvax.dartmouth.edu!news.bu.edu!olivea!hal.com!darkstar.UCSC.EDU!osr From: dfk@wildcat.dartmouth.edu (David Kotz) Newsgroups: comp.os.research Subject: Single-Address-Space Operating Systems Date: 15 Dec 1993 01:35:09 GMT Organization: Dartmouth College, Hanover, NH Lines: 43 Approved: comp-os-research@ftp.cse.ucsc.edu NNTP-Posting-Host: ftp.cse.ucsc.edu Originator: osr@ftp Status: RO There seems to be growing interest in Single-Address-Space Operating Systems (SASOS; sometimes known as 64-bit operating systems, flat address spaces, wide address spaces, etc). The basic idea is to put all processes and files into a single address space. Some systems are object-oriented; some are distributed; some are persistent. After a discussion with several people at SOSP, we decided that it would be helpful to have an email-list of people interested in SASOS issues. Thus, we have created a mailing list for interested parties, including many research groups that are actively building SASOS systems. Feel free to forward this message to anyone you think might be interested. To send mail to the list, mail to sasos@cs.dartmouth.edu To join or get off the mail to the list, mail to sasos-request@cs.dartmouth.edu We have also created an ftp archive on cs.dartmouth.edu that we hope to fill with relevant information. To start, we have two files: list the members of the electronic mailing list sasos.bib a bibliography of related papers [Please be patient with cs.dartmouth.edu over the next few weeks; we've just moved our entire department to a new building and at the moment that machine is quite slow.] Contributions to the directory are welcome. Please send them either to myself or to Preston Crow (crow@cs.dartmouth.edu). We are particularly interested in getting bib entries for any papers you find that are missing from the bibliography (we'll update it from time to time), and a one-paragraph ASCII description of your research project. Pointers to ftp-able papers and TRs are also helpful. David Kotz Assistant Professor Mathematics and Computer Science Dartmouth College 6211 Sudikoff Laboratory, Room 116 Hanover, NH 03755-3510 USA email: David.Kotz@Dartmouth.edu 603-646-1439 From dfk Mon Apr 25 11:46:28 1994 Date: Mon, 13 Dec 93 15:24:28 EST From: dfk To: sasos@cs Subject: New mailing list on Single-Address-Space Operating Systems (SASOS) Status: RO After a discussion with several people at SOSP, we decided that it would be helpful to have an email-list of people interested in Single-Address-Space Operating Systems (SASOS; sometimes known as 64-bit operating systems, flat address spaces, wide address spaces, etc). We have created a mailing list for interested parties, including many research groups that are actively building SASOS systems. We initialized the list (see below) with the names of people we met at SOSP, plus some others we invited. Please forward this message to anyone else you think might be interested. To send mail to the list, mail to sasos@cs.dartmouth.edu To join or get off the mail to the list, mail to sasos-request@cs.dartmouth.edu We have also created an ftp archive on cs.dartmouth.edu that we hope to fill with relevant information. To start, we have two files: list the members of the electronic mailing list (below) sasos.bib a bibliography of related papers [Please be patient with cs.dartmouth.edu over the next few weeks; we've just moved our entire department to a new building and at the moment that machine is quite slow.] Contributions to the directory are welcome. Please send them to one of us. We are particularly interested in getting bib entries for any papers you find that are missing from the bibliography (we'll update it from time to time), and a one-paragraph ASCII description of your research project. David Kotz Assistant Professor Mathematics and Computer Science Dartmouth College 6211 Sudikoff Laboratory, Room 116 Hanover, NH 03755-3510 USA email: David.Kotz@Dartmouth.edu 603-646-1439 Single-Address-Space Operating Systems As of 12/13/93 David Kotz (list maintainer) John Carter Jeff Chase (Opal) Preston Crow Paulo Ferreira (SOR) Ben Gamsa (NUMAchine/Tornado) Kaushik Ghosh (KTK) Jon Inouye (Chorus) Robert Klinkhammer Ram Kordale Sacha Krakowiak R. Andrew McCallum Donald Miller T Okamoto John Rosenberg (MONADS) Stephen Russell (MUNGI) Ashley Saulsbury (Angel) Michael Scott Bart Sears (HP PA-RISC) Tim Wilkinson et al (Angel) From dfk@cs.dartmouth.edu Mon Apr 25 11:46:29 1994 Date: Wed, 22 Dec 93 19:15:13 -0500 From: dfk@cs.dartmouth.edu (David Kotz) To: sasos@cs.dartmouth.edu Subject: SASOS mailing list Status: RO Welcome to the SASOS mailing list. Membership has been growing steadily! There are now 125 addresses (representing > 125 people) on the list. The ftp archive has its first project summary, in pub/sasos/projects/Angel* on cs.dartmouth.edu. Many thanks to the Angel project for this summary. If other groups would like to provide a similar summary, please mail them to this list, and then I'll archive them. If you think of any papers we've missed in the bibliography, feel free to contribute. dave From Stefan_Monnier@NIAGARA.NECTAR.CS.CMU.EDU Mon Apr 25 11:46:30 1994 To: sasos@cs.dartmouth.edu Subject: C and unsafe environments Date: Tue, 25 Jan 94 00:45:37 EST From: Stefan_Monnier@NIAGARA.NECTAR.CS.CMU.EDU Status: RO (this list doesn't seem too active, but..) I'm looking for any kind of information about implementations of C in SASOSes that aren't "inherently" safe (that is, like Cedar or Oberon: they have a language based protection mechanism rather than a hardware based one) Thanks, Stefan From tim@cs.city.ac.uk Mon Apr 25 11:46:30 1994 Date: Tue, 25 Jan 1994 07:51:40 +0000 (GMT) From: Tim Wilkinson Subject: Re: C and unsafe environments To: Stefan_Monnier@NIAGARA.NECTAR.CS.CMU.EDU Cc: sasos@cs.dartmouth.edu In-Reply-To: <28387.759476737@NIAGARA.NECTAR.CS.CMU.EDU> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 25 Jan 1994 Stefan_Monnier@NIAGARA.NECTAR.CS.CMU.EDU wrote: > > (this list doesn't seem too active, but..) > > I'm looking for any kind of information about implementations of C in SASOSes > that aren't "inherently" safe (that is, like Cedar or Oberon: they have a language > based protection mechanism rather than a hardware based one) > > Thanks, > > > Stefan > We've done some work here on adapting C and C++ to SASOS by use of a base segment register to point the the relevant instance of the data segment. A technical report is available: ftp.cs.city.ac.uk:/papers/93/sarc93-1.ps.Z I can also let anyone interested have the necessary patch file to apply to the GCC-2.5.7 source if they're interested. The modifications are all target independent (except for the allocation of a register to the the base segement register). Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From tim@cs.city.ac.uk Mon Apr 25 11:46:32 1994 Date: Tue, 25 Jan 1994 14:52:45 +0000 (GMT) From: Tim Wilkinson Subject: Dynamic linking and dynamic binding in single address space OSs. To: Single Address Space Operating Systems Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO This group has been quiet for too long so ... The single address space kernel we are working on at City desperately requires shared libraries, partly because it has the potential to allow code sharing (so reducing program size), but mostly because our client/server model relies on the the sharing of code. For example, a typical server may create a RPC channel for a client. Currently this is done in C++ so there is the potential for virtual functions to be present, hence virtual tables are used by both parties to call the functions associated with the channel. Because of this, the code for the functions must be available in both protection domains. A shared library containing this code solves the problem. However, it is unclear how such a shared library function can access any data other than that on the stack or using pointers passed on the stack. This is because the library has no notion of the layout of either the client or server's data layout. Once method is to wrap the calls to the library function in a stub to provide the library with data relevant to it; but this involves not only the creation of a data object to associate with the library, but the generation of the code to make the change; and it is not clear whether this wrapper will be the same for both client and server (althought the virtual tables would mean it had to be). Dynamic binding further complicates matters since it cannot be done by modifying the code to point the the selected library (it's shared after all). Therefore, an indirection table must be used and the code associated with it can not be shared either (since the indirection tables position cannot be known to the library). Well, I hope there is in fact something I'm missing here since this is all looking generally icky. By far the simplest solution if to exclude data references from shared libraries except for accesses to known control information pointers (current process and current thread pointers are at the same position in all executables!!). This is probably the initial strategy. Any thoughts anyone? Tim PS. The only satisfying thing about any of this is that it doesn't appear any better for multi-address space systems either. ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From tim@cs.city.ac.uk Mon Apr 25 11:46:33 1994 Date: Wed, 26 Jan 1994 08:04:49 +0000 (GMT) From: Tim Wilkinson Subject: Overview of SASOS project To: Single Address Space Operating Systems Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I have had a number of request for an overview of our SASOS project. This is available online at cs.dartmouth.edu but I've also included it below. I would be interested in similar overviews by other groups working on SASOS projects (Opal, Mungi, Pegasus, etc.). Any how .... The Angel Project - A Brief Overview ==================================== Authors: -------- Tim Wilkinson (tim@cs.city.ac.uk) Ashley Saulsbury (ans@sics.se) Tom Stiemerling Kevin Murray (kam@cs.city.ac.uk) Paul Kelley (phjk@doc.ic.ac.uk) Peter Osmon Introduction ------------ This project was prompted by earlier work at City University on a message passing microkernel and its Unix server (called Meshix [1]). This work developed a distributed microkernel to utilise a message passing, shared nothing processor platform. While this goal was successfully achieved, there were a number of issues regarding Meshix which the group were not satisfied with [2]: * The performance of the message passing system, * The structure of a kernel relying on message passing, * The complex and abstract naming of server interfaces (yet another ad-hoc naming scheme), and * The difficulty of using a message passing paradigm for "real" operating system sevices. These problems led to a number of key ideas, which in combination provided the momentum to start work on the design of a new operating system which was to become Angel. The intention was to abandon the increasingly complex UNIX model, and examine what could be achieved with a simple kernel model and current technology. In doing this, a number of issues were addressed. Naming and the single address space ----------------------------------- The complexity of naming and communicating with servers and the unnecessary overhead of message processing in the Meshix kernel (even when optimised) led to the desire for a simpler naming scheme. Furthermore a naming scheme which was not *yet another* abstract scheme. The perhaps not so obvious choice was to make use of the one naming scheme a processor explicitly supports --- the address space. This decission inevitably leads to a single address space, and such was the kernel design born. However, such an approach is of little merit with only a limited 4 Gigabytes of space available. Fortunately, the decission to adopt a single address space coincided conveniently with the announcement of a very high performance RISC processor in 1991 --- the MIPS R4000. This processor provided an ample (debatably so) 64 bits of naming space. Unification of shared memory and distributed memory --------------------------------------------------- The group at the time was also working on an implementation of Kai Li's DVSM system for the Meshix kernel [3]. We quickly came to the conclusion that a microkernel message passing system like Meshix had some inherent deficiencies. While intellectually appealing, a message passing paradigm is not especially simple to control inside the kernel, and certainly not suitable for many types of operation --- for example, when moving large amounts of data from one process to another. Therefore, a DVSM system implemented *on top* of such a message passing system was not the correct approach. However, the basic concept of DVSM remained very appealing. Looking at other contemporary microkernel technology and forthcoming work, there was a distinct trend toward using a message passing paradigm, but with gratuitous use of shared memory and page-remapping in order to achieve performance. It seemed crazy to force people to use message passing, when the message passing implementation leveraged off shared memory for performance. Surely it was better to provide shared memory as the basic paradigm of the machine, and allow users the choice of whether to build a message passing system on top of that. With shared memory as our basic programming model, the job of handling communication between machines then fell neatly to a DVSM implementation. This tied in logically with our thoughts on a single address space operating system, and the use of the address space as the fundamental naming scheme of the operating system [4]. By adopting this general approach, a number of features came for free. For example, process migration between machines becomes trivial, the work being dealt with transparently by the DVSM. Another example is the ability to provide a cache coherent file system --- a trick which required only the detachment of a memory object from the life of a process. Current Status -------------- For ease of development, the primary kernel construction has been done as an emulation under SunOS [5]. This phase of the work is now complete with versions being used as a basis for other related areas of research (eg. the support of a UNIX environment). The most recent port of the kernel is targeted for a Sparc. However, an earlier native port was completed on a machine with Motorola 88K processors which proved invaluable in keeping the kernel targeted at real architectures. A number of tools have been developed. The most important of these was a C/C++ compiler based on GNU C [6]. This supports the two compilation models required; "spawn" to handle the unknown placement of the data segment (UNIX-like exec semantics), and "fork", which allow creation of duplicate data segments at different address (UNIX-like fork semantics). Work in progress ---------------- A number of sub-projects have been spawned within the group based on the initial kernel version. These include: * Design and construction of a windowing system to be used as the primary user interface. By providing such facilities early on in the project, we hope to avoid being trapped in an old fashioned "80x24" terminal based environment. * Shared library support to allow efficient sharing of code. Single address spaces make sharing code simple but mechanism for coordinating the finer aspects of this system are not complete. * Multiprocessor simulation platform to enable both verification of existing multiprocessor support as well as allowing experimentation with the requirements of a "real" platform. * Fault tolerance additions to the kernel which, although already researched [7], have yet to be added to the system. References ---------- [1] "Topsy: An Extensible UNIX Multicomputer", P. Winterbottom and P. Osmon, City Univesity, ENGLAND. [2] "Evaluating MESHIX---A UNIX compatible Micro-Kernel Operating System", P. Osmon, T. Stiemerling, T. Wilkinson, N. Williams, A. Whitcroft, City University, ENGLAND. EurOpen Autumn '92 Conference Proceedings. [3] "Implementing DVSM on the TOPSY multicomputer", A. Saulsbury, Imperial College, ENGLAND, T. Stiemerling, T. Wilkinson, City University, ENGLAND, Symposium on Experience with Distributed Multicomputer Systems III Newport Beach, March 1992. [4] "Angel: A Proposed Multiprocessor Operating System Kernel", T. Wilkinson, T. Stiemerling, P. Osmon; City University, ENGLAND, A. Saulsbury, P. Kelly; Imperial College, ENGLAND, European Workshop on Parallel Computing March 1992. [5] "Design and Implementation of an Object-Orientated 64-bit Single Address Space Microkernel", K. Murray, T. Wilkinson, P. Osmon, City University, ENGLAND, A. Saulsbury, Swedish Inst. of Comp. Sci., SWEDEN, P. Kelly, Imperial College, ENGLAND, 2nd USENIX Symposium on Microkernels and other Kernel Architectures, San Diego, August 1993. [6] "Compiling for a 64-Bit Single Address Space Architecture", T. Wilkinson, A. Saulsbury, K. Murray, T. Stiemerling, City University, ENGLAND. Technical Report. [7] "Implementing Fault Tolerance in a 64-bit Distributed Operating System" T. Wilkinson, City University, ENGLAND. PhD Thesis. ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From chase@cs.washington.edu Mon Apr 25 11:46:34 1994 To: sasos@cs.dartmouth.edu Subject: the story of Opal Date: Wed, 09 Feb 1994 15:39:50 PST From: Jeff Chase Status: RO Howdy folks. A revised version of "the" Opal paper is now available in postscript by anon ftp to cs.washington.edu. It's TR 93-04-02. This paper will appear in ACM TOCS 5/94. It will probably look familiar, but it has more detail than earlier versions. I will be happy to try to answer any questions you may have, but I apologize that my e-mail responses may be (have been) delayed or terse due to my continuing problems with carpal tunnel syndrome. Here's a quick FAQ: 1. Can I use Opal? Not without great pain. 2. Can I get the code for Opal? We are still trying to stave off requests for the code. The current ETA is summer 94. 3. Can I run Mach on my Alpha? Not without great pain. We can provide a rough list of steps to sculpt a minimal running system out of the CMU MK83 release, thanks to Jan Sanislo, but we advise against it. Brian Bershad's group now has a usable version of the OSF RI release of microkernel Mach. The Opal group is moving to that base, and UW is trying to figure out how to arrange to distribute it, possibly with some additional UW extensions. We will post to sasos when more info is available. 4. Did you modify the Mach kernel for Opal? We should have, and we plan to, but we haven't yet. We are currently ramping up to make some changes to the Mach VM system, and to add kernel support for "portals". Jeff From chase@cs.washington.edu Mon Apr 25 11:46:34 1994 To: sasos@cs.dartmouth.edu Cc: tarcea@Mordor.Stanford.EDU (Glenn Tarcea) Subject: ftp'ing the Opal paper In-Reply-To: Your message of "Wed, 09 Feb 1994 16:31:18 PST." <199402100031.QAA14370@Mordor.Stanford.EDU> Date: Wed, 09 Feb 1994 16:38:23 PST From: Jeff Chase Status: RO Just to clarify, the Opal paper is in the cs.washington.edu ftp directory (ftp-login as "anonymous"): tr/1993/04/UW-CSE-93-04-02.PS.Z Jeff From ben@smile.apdg.com Mon Apr 25 11:46:35 1994 From: "Benjamin J. Black" Date: Thu, 14 Apr 94 09:35:37 -0500 To: sasos@cs.dartmouth.edu Subject: Some thoughts on OOP and SASOS Reply-To: ben@smile.apdg.com Status: RO Hi, I had some thought I want to run by the group regarding OOP and SASOS's. I am posting in the hope of spurring discussion in this mailing list, so please don't flame me if you think this is stupid. In a SASOS based on an object-oriented language the only essential component is the run-time system; everything else is just built on top of that. Would a model such as this provide more flexibility than is typical of even microkernels such as Mach, or must you end up with a system like Smalltalk or Self? I see one of the major issues in SASOS's to be naming conflicts. Using an OO language helps by creating a 2-level naming hierarchy (global object names and local method/instance variable names). Would extending the hierarchy to more levels while maintaining the features of an object (encapsulation especially) be a reasonable solution? I realize that you end up with the software protection domains used in most current SASOS projects, but the model is consistent across all levels and the implicit protection domains remove some programming complexity (IMHO). Huge address spaces eliminate the need for a traditional filesystem (filesystems, I think. were really just a hack to get around memory and address space limitations). The typical approach now is to simply use all of secondary storage as swap space handled by the virtual memory system. However, using a standard VM system gives poor performance in many cases because it is not intended to deal with large or multiple disks. More appropriate than a VM system would be an OODBMS. DBMS's typically control more precisely how data is laid out on disks and are better equipped to handle normal user requests (searching a VM system for data based on a user-defined query is an unpleasant thought). An OODBMS would also better handle the issue of persistence. Well, how about some discussion (or are these just too boring to even waste the bandwidth?)... Ben ben@apdg.com From mjs@cs.cornell.edu Mon Apr 25 11:46:36 1994 From: mjs@cs.cornell.edu (Marc Shapiro) Date: Thu, 14 Apr 94 13:27:35 -0400 To: ben@smile.apdg.com Cc: sasos@cs.dartmouth.edu In-Reply-To: "Benjamin J. Black"'s message of Thu, 14 Apr 94 09:35:37 -0500 <9404141435.AA06189@smile.apdg.com> Subject: Some thoughts on OOP and SASOS Status: RO || From: "Benjamin J. Black" || Date: Thu, 14 Apr 94 09:35:37 -0500 || || Huge address spaces eliminate the need for a traditional || filesystem (filesystems, I think. were really just a hack to get || around memory and address space limitations). One nice property of the process/file separation is that all temporary storage is reclaimed automatically when your process exits. Remember that programs generate a lot of junk (intermediate results of all sorts). In traditional Unix-style systems most of this junk goes away when your process exits. Much of the other junk you were carefully to manually separate from the long-term data by putting it into /tmp files or into pipes. There is still the need for some manual cleaning after the fact but much of it is taken care of by stylized interfaces like 'make clean'. To get the same effect in a very flat system where all data is potentially persistent, you need to have pretty good garbage detection. As you can imagine, efficient distributed GC is a hard problem. It's even harder in a SASOS. (Well, it just so happens that my group is working on this problem and we have some interesting results.) || The typical approach now is to simply use all of secondary storage || as swap space handled by the virtual memory system. What a terrible idea. If your virtual address space is 64 bits wide, you need 2**64 bytes of physical disk storage. Do you think any system administrator will accept that? And if he did, would he be willing to dedicate a large portion this expensive resource to what is liable to be mostly garbage? What about framgmentation? What about working sets? Something of the sort will only work with (again) garbage collection and compaction of the fragmented space. Marc Shapiro M. Shapiro, INRIA, on sabbatical at Cornell University, 4106 Upson Hall, Ithaca NY 14583, USA; e-mail: mjs@cs.cornell.edu tel.: +1(607)255-5418; fax: +1(607)255-4428 From ben@smile.apdg.com Mon Apr 25 11:46:37 1994 From: "Benjamin J. Black" Date: Thu, 14 Apr 94 12:48:28 -0500 To: sasos@cs.dartmouth.edu Subject: Re: Some thoughts on OOP and SASOS Reply-To: ben@smile.apdg.com Status: RO > From: mjs@cs.cornell.edu (Marc Shapiro) > Date: Thu, 14 Apr 94 13:27:35 -0400 > > One nice property of the process/file separation is that all temporary > storage is reclaimed automatically when your process exits. Remember > that programs generate a lot of junk (intermediate results of all > sorts). In traditional Unix-style systems most of this junk goes away > when your process exits. Much of the other junk you were carefully to > manually separate from the long-term data by putting it into /tmp > files or into pipes. There is still the need for some manual cleaning > after the fact but much of it is taken care of by stylized interfaces > like 'make clean'. > True in Unix, but if you are going to rely on a GC system, why wouldn't you invoke it while the process was running? Certainly, if you allowed the process to run to completion without garbage collection there would be a tremendous amount of work at termination, but, if you collect incrementally, termination should only be slightly more complex than a standard collection pass. > || The typical approach now is to simply use all of secondary storage > || as swap space handled by the virtual memory system. > > What a terrible idea. If your virtual address space is 64 bits wide, > you need 2**64 bytes of physical disk storage. Do you think any > system administrator will accept that? And if he did, would he be > willing to dedicate a large portion this expensive resource to what is > liable to be mostly garbage? What about framgmentation? What about > working sets? Something of the sort will only work with (again) > garbage collection and compaction of the fragmented space. > I didn't mean that a single user would be allocated the entire 64bits of the address space, nor did I mean that a system would _have_ to have enough disks to allocate that much storage at one time. Of course garbage collection and compaction would be needed, but isn't that what current virtual memory systems do? My point is that standard virtual memory systems are not adequate for use as storage managers in a SASOS (just look at the weak I/O performance of the KSR-1). What is needed is a system which has much more control over the manipulation of the secondary storage system, hence my suggestion that what is needed is something more like an OODBMS. Ben ben@apdg.com From ikim@enws237.eas.asu.edu Mon Apr 25 11:46:38 1994 Date: Thu, 14 Apr 94 14:38:55 MST From: ikim@enws237.eas.asu.edu (Ilmin Kim) To: sasos@cs.dartmouth.edu Subject: ftp address of Mungi & Angel papers Status: RO Hello! I'm new here! (the first impression is really fantastic) By the way, I'd like to get new versions of papers about Mungi & Angel. Any body know about ftp addresses for those SASOS systems. Thanks in advance. --- Kim P.S. I love Mungi system From chase@cs.washington.edu Mon Apr 25 11:46:38 1994 To: sasos@cs.dartmouth.edu cc: chase@cs.washington.edu Subject: Re: garbage in an SASOS In-reply-to: Your message of "Thu, 14 Apr 1994 13:27:35 EDT." <9404141727.AA23303@grimnir.cs.cornell.edu> Date: Thu, 14 Apr 1994 15:11:15 PDT From: Jeff Chase Status: RO Marc Shapiro says: > > One nice property of the process/file separation is that all temporary > storage is reclaimed automatically when your process exits. Remember > that programs generate a lot of junk (intermediate results of all > sorts). In traditional Unix-style systems most of this junk goes away > when your process exits. Much of the other junk you were carefully to > manually separate from the long-term data by putting it into /tmp > files or into pipes. ... > > To get the same effect in a very flat system where all data is > potentially persistent, you need to have pretty good garbage > detection. I want to briefly add the Opal viewpoint to this discussion. Flat address spaces give you uniform naming, which is great. But viewing the address space as monolithic complicates address space management and storage management. You need to add some structure and constraint back in. This is why Opal's SAS is partitioned into segments. Segments are the grain of VAS allocation, access control, and paging policy. Objects are allocated within particular segments: each thread has a "current segment" for new() and malloc(). The current segment can be changed with a runtime system call, so programs can easily spread their data structures across multiple segments. Note that segments are completely transparent to simple programs, and to code that follows pointers or builds data structures. In particular, segments do not affect the naming model. The address space is still flat, not segmented like Multics. Opal segments are also the grain of virtual address space allocation and reclamation -- at the system level. The key point I want to make is that if an application can separate its long-term data and its transient garbage (as in Unix), then we can still reclaim the transient segments, in bulk when the program terminates, just like Unix. It is not at all different. In particular, Opal cleans up after simple programs (those that use only transient data) in the same way that Unix does: by reclaiming the program's segments automatically when the program terminates. Private address spaces don't buy you anything here, and a single address space doesn't hurt you in any way. > As you can imagine, efficient distributed GC is a hard > problem. It's even harder in a SASOS. > > (Well, it just so happens that my group is working on this problem and > we have some interesting results.) Although bulk reclaiming of transient segments is trivial, object-based garbage collection is of course essential, as always, for reclaiming data structures within persistent segments. This is why we are so interested in Marc Shapiro's work. - Jeff From kevine@vast.unsw.edu.au Mon Apr 25 11:46:39 1994 To: ikim@enws237.eas.asu.edu (Ilmin Kim) Cc: sasos@cs.dartmouth.edu Subject: Re: ftp address of Mungi & Angel papers In-Reply-To: Your message of "Thu, 14 Apr 1994 14:38:55 MST." <9404142138.AA01231@enws237.eas.asu.edu> Date: Fri, 15 Apr 1994 16:38:09 +1000 From: Kevin Elphinstone Status: RO >>>>> ikim@enws237.eas.asu.edu (Ilmin Kim) writes: Ilmin> By the way, I'd like to get new versions of papers about Mungi & Ilmin> Angel. Any body know about ftp addresses for those SASOS Ilmin> systems. The Mungi tech reports are available in postscript form from ftp.vast.unsw.edu.au:/pub/Mungi. The reports have recently been regenerated to avoid some problems people have reported when trying to print them. So please try again if you have had problems printing them in the past. - Kevin From ben@smile.apdg.com Mon Apr 25 11:46:40 1994 From: "Benjamin J. Black" Date: Fri, 15 Apr 94 08:11:00 -0500 To: sasos@cs.dartmouth.edu Subject: Status of SASOS projects Reply-To: ben@smile.apdg.com Status: RO Hi, What is the current status of the existing SASOS implementation projects? I mean by this, how complete/stable is the current code? How well documented are the systems? I feel that one of the reasons Mach has become so popular is the copious documentation, and I would like to see something similar for a SASOS project. Anyone? Ben ben@apdg.com From ben@smile.apdg.com Mon Apr 25 11:46:41 1994 From: "Benjamin J. Black" Date: Fri, 15 Apr 94 08:23:36 -0500 To: sasos@cs.dartmouth.edu Subject: Garbage collection Reply-To: ben@smile.apdg.com Status: RO Hi, Since no one seemed particularly interested in talking about anything other than GC, I'll post on that topic. What if every process had a thread associated with it whose only purpose was to monitor memory usage constantly during the life of the process, and would then assist the GC system in locating free-able objects. Obviously, other useful information could also be collected with such a setup. How difficult/useful would this really be? Ben ben@apdg.com From ben@smile.apdg.com Mon Apr 25 11:46:42 1994 From: "Benjamin J. Black" Date: Fri, 15 Apr 94 09:30:57 -0500 To: mjs@cs.cornell.edu (Marc Shapiro) Subject: Re: Garbage collection Cc: sasos@cs.dartmouth.edu Reply-To: ben@smile.apdg.com Status: RO > From: mjs@cs.cornell.edu (Marc Shapiro) > Date: Fri, 15 Apr 94 10:24:54 -0400 > > || From: "Benjamin J. Black" > || Date: Fri, 15 Apr 94 08:23:36 -0500 > || > || What if every process had a thread associated with it whose only > || purpose was to monitor memory usage constantly during the life of > || the process, and would then assist the GC system in locating > || free-able objects. > > I'm not sure I understand what you are trying to say. How is that > monitoring process different from a per-application garbage collector? > I think my solution would be much lighter weight in both computation and memory cost than a full garbage collector for every process. In my system the monitoring process just collects the data that the global garbage collector will use. This will have a similar effect (same?) to a per-process GC, but it will not be as expensive. Ben ben@apdg.com From smr@vast.unsw.edu.au Mon Apr 25 11:46:43 1994 From: Steve Russell Subject: Re: Some thoughts on OOP and SASOS To: mjs@cs.cornell.edu (Marc Shapiro) Date: Sun, 17 Apr 1994 13:39:31 +1000 (EST) Cc: ben@smile.apdg.com, sasos@cs.dartmouth.edu In-Reply-To: <9404141727.AA23303@grimnir.cs.cornell.edu> from "Marc Shapiro" at Apr 14, 94 01:27:35 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2435 Status: RO > [Marc Shapiro writes ...] > One nice property of the process/file separation is that all temporary > storage is reclaimed automatically when your process exits. .... > > To get the same effect in a very flat system where all data is > potentially persistent, you need to have pretty good garbage > detection. ... I think Jeff's covered this pretty well. Mungi uses a similar scheme to Opal. In our case, all memory is allocated as non-persistent -- we keep a `kill list' per thread. Making the memory persistent removes it from the list, and is done explicitly by the app. Of course, our approach is no better than Unix -- temp storage is removed automatically on thread death, but things like files linger on. That's not to say that Marc is wrong to point out the need for GC. Unlike Unix, Mungi doesn't (can't) keep ref counts (same for Opal, Jeff?). We agree that `conventional' GC schemes are not easily adapted, as Marc points out. We're investigating alternative schemes that don't try to detect garbage, but just make it unprofitable for users to create it. (Not much new here -- Amoeba proposed similar ideas years ago.) > What a terrible idea. If your virtual address space is 64 bits wide, > you need 2**64 bytes of physical disk storage. And I suppose that means that Unix on an Alpha, R4000, et al needs 2**64 bytes per process? Come on, Marc, you can do better :-) ... > What about fragmentation? See, I told you ... yep, fragmentation is a problem, but not as bad as you think. It doesn't affect physical storage much, depending on assumptions re object sizes and page sizes. Our simulations show, with a Unix like workload, you get exactly the results that led BSD to introduce 8K/1K `page' sizes for the file system (no big surprise). We're currently looking at clever TLB refill models that allow for variable page sizes to minimise physical fragmentation. > Something of the sort will only work with (again) > garbage collection and compaction of the fragmented space. Depends what you mean by ``work''. Fragmentation of the virtual space is only a problem if you can't re-use VA's -- even 64 bits fills up too quickly otherwise. So, you need an allocation/protection model that allows re-use, and a garbage management model that minimises leakage. There is no need for compaction of the virtual space; which is lucky, cause it would be impossible anyway. Thanks for the input, Marc. Cheers, Steve. From smr@vast.unsw.edu.au Mon Apr 25 11:46:44 1994 From: Steve Russell Subject: Re: Status of SASOS projects To: ben@smile.apdg.com Date: Sun, 17 Apr 1994 13:44:53 +1000 (EST) Cc: sasos@cs.dartmouth.edu In-Reply-To: <9404151309.AA07509@smile.apdg.com> from "Benjamin J. Black" at Apr 15, 94 08:11:00 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 375 Status: RO > What is the current status of the existing SASOS implementation > projects? I mean by this, how complete/stable is the current code? How well > documented are the systems? I think you'll find they're all ``pre-alpha'' :-). Mungi is being held back by some silly squabbling with our University over who we can hire and fire with our own grant funds. Cheers, Steve. From chase@cs.washington.edu Mon Apr 25 11:46:45 1994 To: sasos@cs.dartmouth.edu Subject: Re: Some thoughts on OOP and SASOS In-reply-to: Your message of "Sun, 17 Apr 1994 13:39:31 +1000." <9404170339.AA08559@miter> Date: Sun, 17 Apr 1994 14:49:44 PDT From: Jeff Chase Status: RO > [Steve Russell writes ...] > Unlike Unix, Mungi doesn't (can't) keep ref counts (same for Opal, > Jeff?). The Opal system itself does not count references to language objects. That is the responsibility of the language environment (e.g., Marc's garbage collectors), when it is needed. However, Opal segments are reference-counted. The counts are incremented implicitly when a segment is attached to a protection domain, or explicitly by the application, using a system call. This is intended as a hook for your garbage collector. This is why we say that Opal segments are "potentially persistent". If your application does nothing special, all segments will be reclaimed on last detach, i.e., when your program terminates. But if you increment the count, then Opal will preserve the segment's address bindings and backing storage, and the segment will stick around for future use, until some other piece of user code calls back and decrements the count back to zero. Of course, any persistent segments you create will be "charged" to you through an accounting mechanism, just like in Unix (e.g., when you create a hard link to a file). This doesn't prevent users and their programs >from creating garbage, but it does "encourage" them to use Marc's garbage collectors. A 64-bit address space does not mean never having to say you're sorry. > [Marc Shapiro comments on the use of swap space:] > > What a terrible idea. If your virtual address space is 64 bits wide, > > you need 2**64 bytes of physical disk storage. > > [Steve Russell responds:] > And I suppose that means that Unix on an Alpha, R4000, et al needs > 2**64 bytes per process? Come on, Marc, you can do better :-) ... This is actually funnier than you think. In my experience, the current DEC OSF/1 Alpha release will not permit a Unix process to use more than a gigabyte of address space...perhaps limited by swap in my configuration. You can turn off eager swap allocation -- at config time, I think -- but I ran into the same limit when I tried mapping files. Take this with salt, but it is a fact that some people believe that lazy swap allocation *is* a bad idea, and some of them are building wide-address Unix systems. - Jeff From tim@cs.city.ac.uk Mon Apr 25 11:46:45 1994 Date: Mon, 18 Apr 1994 08:59:18 +0100 (BST) From: Tim Wilkinson Subject: Re: Some thoughts on OOP and SASOS To: Single Address Space Operating Systems In-Reply-To: <9404170339.AA08559@miter> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 17 Apr 1994, Steve Russell wrote: > ........................................ Mungi uses a similar scheme to > Opal. In our case, all memory is allocated as non-persistent -- we keep > a `kill list' per thread. Making the memory persistent removes it from > the list, and is done explicitly by the app. Of course, our approach > is no better than Unix -- temp storage is removed automatically on > thread death, but things like files linger on. In Angel we take the reverse approach. All memory objects are persistent as long as they have a capability in existant which references them. However, when an object is in use within a virtual processor's protection domain and the VP terminates, all capabilities within the current domain are deleted. Hence, any objects which are only referenced by that capability are also removed. Additionally, to avoid creation of unreferenced objects (where the intial capability is lost), we automatically insert the object into the creating VP's domain (which is usually the desire anyhow). This allows for simple creation of temporary objects. The down side of this capability deletion is an increased care when getting and resolving objects from the external namespace into domains since if they are left resolved, the associated object may be unexpectedly deleted. However, this is solved by capability duplication when getting a capability >from a namer. The major advantage of this is that it allows objects to be removed even if they are active in other domains (unlink open files in UNIX for example). There is also little kernel support, all reference counting is handled in an external user-level object manager. It is only necessary for the kernel to inform if of the capbalities in the domain of a terminating VP. Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From Paulo.Ferreira@inria.fr Mon Apr 25 11:46:47 1994 From: Paulo.Ferreira@inria.fr Date: Mon, 18 Apr 1994 11:23:36 +0200 To: sasos@cs.dartmouth.edu Subject: Garbage collection Status: RO Hi, As Marc Shapiro as already mentioned, we are working on the subject of Garbage Collection in Distributed Shared Memory in a large 64-bit address space that spans several machines in a network including secondary storage. Starting from what Jeff said: > Although bulk reclaiming of transient segments is trivial, > object-based garbage collection is of course essential, as > always, for reclaiming data structures within persistent > segments. This is why we are so interested in Marc Shapiro's > work. Our system (called BMX) provides support for distributed and persistent objects that are allocated inside segments; segments are logically grouped into bunches. Each bunch can be independently garbage collected wich allows a high degree of parallelism and scalability. Thus, there are three levels of Garbage Collection: 1 - Bunch Garbage Collection (BGC) that collects a bunch independently from any other. 2 - Distributed Garbage Collects (DGC) that simply propagates accesibility information between bunches. 3 - Global Garbage Collection (GGC) that logically groups bunches and collect them as a whole in order to get rid of inter-bunch cycles of garbage. The problem is on maintaining inter-bunch reference information in order to allow independent BGC; we do this through the use of auxilary data structures called stubs and scions. An interesting point is that by making the GC aware of the consistency protocol (we use entry consistency) we manage to have almost no cost due to inter-bunch references that are usually costly to handle when bunches are mapped on different nodes. This mail is already long; if you are interested on more detail, you may ftp the following paper describing our BMX system: machine -> ftp.inria.fr directory -> /INRIA/Projects/SOR file -> iwooos:ferreira.ps.gz The paper describing our garbage collection design is still a draft. However, if you are really interested send me a mail. I hope to to have a final version accessible by ftp in a few weeks. I'll be glad to have comments from you. --Paulo Ferreira-- ============================================================================= INRIA-ROCQUENCOURT (Paulo.Ferreira@inria.fr) Projet SOR (batiment 52) - Domaine de Voluceau - B.P. 105 Rocquencourt 78153 Le Chesnay Cedex France Tel.: +33(1)39-63-52-08 fax.: +33(1)39-63-53-30 ============================================================================= also affiliated with: (pjpf@inesc.inesc.pt) INESC - Instituto de Engenharia de Sistemas e Computadores R. Alves Redol 9 - 6, 1000 Lisboa, PORTUGAL Phone: (351)-1-3100247 ============================================================================= From kram@cc.gatech.edu Mon Apr 25 11:46:48 1994 From: kram@cc.gatech.edu (Ram M Kordale) Subject: Re: Garbage collection To: Paulo.Ferreira@inria.fr Date: Mon, 18 Apr 1994 09:00:28 -0400 (EDT) Cc: sasos@cs.dartmouth.edu In-Reply-To: <9404180923.AA13905@dormeur.inria.fr> from "Paulo.Ferreira@inria.fr" at Apr 18, 94 11:23:36 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 730 Status: RO > Our system (called BMX) provides support for distributed and > persistent objects that are allocated inside segments; segments are > logically grouped into bunches. Each bunch can be independently > garbage collected wich allows a high degree of parallelism and > scalability. Thus, there are three levels of Garbage Collection: > Since there has been a lot of talk about how the systems have been structured, I was wondering if any of the groups have any real applications running on top of them - are these truly distributed applications(or are they parallel applications). Even if only simulation studies have been done, what are the sample applications(atleast their characteristics)? Any papers, pointers...? Thanks, Ram From ben@smile.apdg.com Mon Apr 25 11:46:49 1994 From: "Benjamin J. Black" Date: Mon, 18 Apr 94 08:56:54 -0500 To: sasos@cs.dartmouth.edu Subject: GC papers on the net Reply-To: ben@smile.apdg.com Status: RO I thought I'd post a few FTP sites with good papers on GC and distributed object systems. Please add on more as I am sure there are lots out there. Ben ben@apdg.com -- cs.utexas.edu:/pub/garbage Papers from GC90,91,and 93, survey papers on GC and DGC, and stuff on RTGC. ftp.daimi.aau.dk:/pub/thesis/gcthesis.ps.Z A thesis on incremental GC using the Train Algorithm. helios.cc.gatech.edu:/pub/{clide, oopsla-olda, papers} OOPSLA papers and reports from the Clouds project. cui.unige.ch:/OO-articles Reports and theses on the OO/distributed languages Hybrid and Cell (among other neat things). From Paulo.Ferreira@inria.fr Mon Apr 25 11:46:49 1994 From: Paulo.Ferreira@inria.fr Date: Mon, 18 Apr 1994 16:18:48 +0200 To: ben@smile.apdg.com Cc: sasos@cs.dartmouth.edu In-Reply-To: <9404181357.AA10856@smile.apdg.com> (ben@smile.apdg.com) Subject: Re: GC papers on the net Status: RO From: "Benjamin J. Black" Date: Mon, 18 Apr 94 08:56:54 -0500 Reply-To: ben@smile.apdg.com > Please add on more as I am sure there are lots out there. See also: ftp.inria.fr:/INRIA/Projects/SOR Papers from the SOR group on object-oriented systems and garbage collection. (see INDEX file) --Paulo-- From shap@viper.cis.upenn.edu Mon Apr 25 11:46:50 1994 Date: Mon, 18 Apr 94 10:27:24 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: sasos@cs.dartmouth.edu In-Reply-To: (message from Tim Wilkinson on Mon, 18 Apr 1994 08:59:18 +0100 (BST)) Subject: Storage Reclamation Status: RO In the context of a persistent system, the notion of temporary storage at the system level is a think-o. There should not be any temporary storage. If your system is persistent, all the storage you'll ever have was allocated when the disks were formatted. All the system can do is transfer the objects across administrative and accounting control boundaries. In KeyKOS, there are two fundamental objects: pages and nodes. A page is what you expect. A Node is an array of exactly 16 (possibly null) capabilities. These objects are persistent (supported by an efficient checkpoint). There are no exceptions - ALL instances of nodes and pages are persistent. Segments, Meters (the scheduling mechanism), and Domains are built out of Nodes. Domains are both the holders of authorities and the closest thing to a thread in the system model. To allocate storage, a domain must posess a capability to a Space Bank. It asks the space bank (which is itself a domain) for a page/node, and a capability is returned. For later bulk reclamation, a domain can ask a Space Bank for a child space bank (sometimes called a subspace bank). Destruction of the subspace bank implicitly reclaims all of the pages allocated through it. This is a common programmer paradigm, and has proven in practice to be quite satisfactory. Pages and nodes are accountable persistent resources (and can be charged for). The model is that if you buy the page and lose it, you've still bought the page, and it's not our job to steal it from you (thus GC is deprecated). More realistically, since Nodes live in kernel space only and persist, it is possible to build a GC mechanism if desired. This wasn't done, as the security implications deserve serious thought. The hard part of the problem is deciding to whom (for accounting purposes) the page should be returned. Consider this especially in a context where the microkernel is a pure capability system, and thus has no notion of "user" that can be conveyed to the GC mechanism. The accounting architecture quickly grows complex. Jonathan From shap@viper.cis.upenn.edu Mon Apr 25 11:46:51 1994 Date: Mon, 18 Apr 94 10:32:58 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: kram@cc.gatech.edu Cc: Paulo.Ferreira@inria.fr, sasos@cs.dartmouth.edu In-Reply-To: <199404181300.JAA16864@forge.cc.gatech.edu> (kram@cc.gatech.edu) Subject: Re: Garbage collection Status: RO Since there has been a lot of talk about how the systems have been structured, I was wondering if any of the groups have any real applications running on top of them - are these truly distributed applications(or are they parallel applications). Even if only simulation studies have been done, what are the sample applications(atleast their characteristics)? Any papers, pointers...? The KeyKOS system had several industrial apps running on it. It was originally known as Gnosis, and was developed by Tymshare. If I recall correctly, they built a major transaction processing application that outperformed DB/2 (the competitor of the day). The system was in the field for a total of 1.5 calendar years at two sites (3.0 run-time years), and ran without a single unplanned outage. It was shut down because Tymshare sold the unit to McDonnel Douglass. There are several papers on the system in the past couple of USENIX microkernel conferences. There's also an old paper in OSR. I have postscript for a number of them and references for the remainder. Would someone be willing to put up a directory on an anonymous FTP archive for them? It's three papers, and I'll be happy to make them available (with permission, even!). From kram@cc.gatech.edu Mon Apr 25 11:46:52 1994 From: kram@cc.gatech.edu (Ram M Kordale) Subject: Re: GC papers on the net To: Paulo.Ferreira@inria.fr Date: Mon, 18 Apr 1994 10:34:53 -0400 (EDT) Cc: ben@smile.apdg.com, sasos@cs.dartmouth.edu In-Reply-To: <9404181418.AA00555@dormeur.inria.fr> from "Paulo.Ferreira@inria.fr" at Apr 18, 94 04:18:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 535 Status: RO From: "Benjamin J. Black" Date: Mon, 18 Apr 94 08:56:54 -0500 Reply-To: ben@smile.apdg.com > Please add on more as I am sure there are lots out there. My plug!-) ...ram @inproceedings{KAS93, key="Kordale et al.", Author="R. Kordale and M. Ahamad and J. Shilling", Title="Distributed/Concurrent Garbage Collection for Distributed Shared Memory Systems", Year=1993, Month="Dec.", Booktitle="International Workshop on Object Orientation in Operating Systems(I-WOOOS)", Organization="IEEE", } From smr@vast.unsw.edu.au Mon Apr 25 11:46:53 1994 From: Steve Russell Subject: Re: Some thoughts on OOP and SASOS To: tim@cs.city.ac.uk (Tim Wilkinson) Date: Tue, 19 Apr 1994 12:56:16 +1000 (EST) Cc: sasos@cs.dartmouth.edu In-Reply-To: from "Tim Wilkinson" at Apr 18, 94 08:59:18 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1038 Status: RO > [Tim writes ...] > In Angel we take the reverse approach [to Mungi]. All memory objects are persistent > as long as they have a capability in existant which references them. And I guess this is the point where we disagree. The protection of our capabilities doesn't rely upon them being kernel objects. The upside is that users can store capabilities in their own data structures, pass them in messages, etc. The downside is that the system can't recognise capabilities, reference count them, etc, so garbage collectors like Marc's are out _at the kernel level_. Now, in spite of Marc's comment at the last IWOOOS that some SASOS people (like us) are "building systems to allow people to write everything in C" (or words to that effect), we really are not advocating such a stand. Like Jeff, we see the problem being `solved' at a language/application level, whereas Marc see object support as a necessary kernel feature. Who's right? That's the fun, isn't it. Nice to see this mailing list warming up. Thanks, Tim. Cheers, Steve. From tim@cs.city.ac.uk Mon Apr 25 11:46:54 1994 Date: Tue, 19 Apr 1994 08:19:20 +0100 (BST) From: Tim Wilkinson Subject: Re: Some thoughts on OOP and SASOS To: Single Address Space Operating Systems In-Reply-To: <9404190256.AA10308@miter> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 19 Apr 1994, Steve Russell wrote: > > [Tim writes ...] > > In Angel we take the reverse approach [to Mungi]. All memory objects are persistent > > as long as they have a capability in existant which references them. > > And I guess this is the point where we disagree. The protection of our > capabilities doesn't rely upon them being kernel objects. The upside is > that users can store capabilities in their own data structures, pass > them in messages, etc. The downside is that the system can't recognise > capabilities, reference count them, etc, so garbage collectors like > Marc's are out _at the kernel level_. I think I've been slighly misunderstood here. The kernel does not keep capabilities (which for some reason are called biscuits round here - strange but true) in special objects. In fact, the kernel doesn't event know what a capability looks like. All it does when a process terminates is delete the current domain, which informs the external object manager. It is this object manager which manages the capabilities and consequently empties the deleted domain of its contents by removing the capabilities which were used to resolve the objects into this domain in the first place. Now, the actual format of these capabilities and where they are stored is purely arbitrary (so far as the kernel's concerned). However, the object manger only creates new capabilities if they are minted with it. This does not stop previously created capabilities from being copied and stored in multiple places, only that when one copy is invalidated, all the other copies are too. > Now, in spite of Marc's comment at the last IWOOOS that some SASOS > people (like us) are "building systems to allow people to write > everything in C" (or words to that effect), we really are not > advocating such a stand. Like Jeff, we see the problem being `solved' > at a language/application level, whereas Marc see object support as a > necessary kernel feature. As for this; well admittedly everything we're doing with Angel at the moment is in C or, mostly, C++. However, we are more interested in using it as a platform for more interesting language issues. A parttime Ph.D. student here is particularly interested in uses for Linda in this environment. I certainly don't believe it is the operating systems task to manage objects in the style of "insert you favourate object oriented language here" no more than I see its task as providing a filesystem or threads. Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From tim@cs.city.ac.uk Mon Apr 25 11:46:54 1994 Date: Thu, 21 Apr 1994 14:00:48 +0100 (BST) From: Tim Wilkinson Subject: Issues of naming in SASOSs To: Single Address Space Operating Systems Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Does anyone have any strong beliefs on entity naming, esp. wrt. single address space operating systems? The obvious base level is the address space which allows all object within it to be named in a uniform manner. However, what about naming entities not in this space, if indeed there are any? Also, what naming scheme should be presented to the users and applications? Currently we are concentrating on naming all thing at the system level by address while providing a personal hierachy of symbolic names for users (built >from a global hierarchy). How are other SASOS systems tackling this issue? Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From gernot@vast.unsw.edu.au Mon Apr 25 11:46:55 1994 To: sasos@cs.dartmouth.edu Reply-To: "Gernot Heiser" Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Subject: The Mungi Manifesto Date: Fri, 22 Apr 1994 16:29:30 +1000 From: Gernot Heiser Content-Length: 3201 Status: RO THE MUNGI MANIFESTO The design of Mungi is based on the following principles: - a single, flat virtual address space, - orthogonal persistence, - a strong but unintrusive protection model. The single address space incorporates all memory objects on all nodes in a distributed system. There are no user-visible memory hierarchies, no file system. Any memory object is potentially persistent, i.e. can outlive its creator process. All objects are uniquely identified by their virtual address, which is a 64-bit number. Any object is potentially accessible by any process, provided the process is authorised to do so. Sharing is trivially achieved by exchanging addresses (and passwords, if required). As there is no file system, all the secondary memory in the system is nothing but paging store. The address of an object does per se not give any indication on where the object is located, and there is really no such concept as "location" at the user level. If a process references a non-resident object, the kernel will obtain a copy and store it in local primary memory. This is not different from paging in traditional VM systems, except that a page may be obtained from disk _or_ across the network. Memory is allocated in (page aligned) chunks called "objects". (Others may call them segments, but we wanted to avoid the connotation of segmented memory.) An object is the unit of protection. No other structure on objects is assumed by the system, but higher software layers are free to impose structure. Protection is based upon password capabilities, address-password pairs. Any holder of a valid capability to an object can access that object. Capabilities can be passed around freely, they are not system objects, but protected by sparsity. Objects do not need to be explicitly attached to a process: if the user deposits their capabilities in a system-maintained data structure, the system will transparently attach the object once it is accessed. This allows execution of programs that have no knowledge of the operation of the protection system. This is the basic philosophy. A few practical points: - There are, of course, directory services to map UNIX-style path names onto object addresses. These are, however, user-level services, the system doesn't care about them. - While all objects are persistent in principle, any new object created is entered into a "cleanup" list. When the process exits, the kernel deallocates all objects pointed to by this list. The process can at any time remove any object from this list and thus make it truly persistent. - While all objects are globally visible in principle, objects are not necessarily entered immediately into the appropriate system data structures to make them globally known. On creation, objects can be tagged as "private" in which case they never become globally known (until the creator process explicitly makes them "public"). This allows fast allocation and deallocation of objects that are unlikely to be shared (e.g. program stacks). Further details can be found in papers available from ftp.vast.unsw.edu.au:pub/Mungi. PS: the presently accepted pronunciation of Mungi is approximately "mahn-guy". From ben@london.apdg.com Mon Apr 25 11:46:56 1994 Date: Fri, 22 Apr 94 16:23:33 +0100 From: "Benjamin J. Black" To: sasos@cs.dartmouth.edu Subject: Re: Issues of naming in SASOSs Status: RO > Does anyone have any strong beliefs on entity naming, esp. wrt. single > address space operating systems? I put forward an idea on this a few days ago, but no one seemed to be interested in anything but GC. I suggested that standard OO languages introduce a 2 level naming hierarchy: objects and instance variables/methods (or whatever terminology you prefer). I wondered what value there would be to extending this hierarchy to more levels. Would this not give a more consistent view to programmers than ad hoc methods intrduced in other systems? How would such a system be realized? I simply don't feel that hierarchies of objects, as seen in filesystems, are appropriate for the management of the billions of names in a SASOS, but that isn't what I am proposing here. Ben ben@apdg.com From saunier@mururoa.imag.fr Mon Apr 25 11:46:57 1994 Date: Fri, 22 Apr 94 18:07:04 +0200 From: saunier@mururoa.imag.fr (Frederic Saunier) To: sasos@cs.dartmouth.edu Subject: Position paper (Was: Some thoughts on OOP and SASOS) Reply-To: sasos@cs.dartmouth.edu, Xavier.Rousset@imag.fr, Jacques.Mossiere@imag.fr Status: RO Hi, I have included below a version of a position paper "SINGLE ADDRESS SPACE OR PRIVATE ADDRESS SPACES ?" This paper has been submitted to 6th european SIGOPS workshop. Of course, any comments are welcome. Sincerely, Frederic Saunier. _____________ BEGIN OF PAPER ______________________________________________ SINGLE ADDRESS SPACE OR PRIVATE ADDRESS SPACES ? Jacques Mossiere, Xavier Rousset de Pina Bull-IMAG/systemes, 2 avenue de Vignate, F 38610 Gieres {Jacques.Mossiere,Xavier.Rousset}@imag.fr 1. INTRODUCTION The appearance of 64 bit address space architectures (DEC Alpha, HP P/A RISC and MIPS R4000), has fostered interest in single address space operating systems. Examples of such implementations are Opal[ChaseJ1994], Angel [MurrayJ1993 ] and [HeiserJ1993] . They all offer the following advantages: % a virtual address is the universal means to reference any object in the system; therefore, there is no need for pointer swizzling, % when an object is deleted, and because of the size of the address space, there is no need for address reutilization, with the expensive problems it implies (address ambiguities, dangling pointers), % and, last but not least, any application program or data in the system may be statically linked. The main challenge is probably the design and implementation of a protection scheme to limit the access rights of each thread or application running in the single space. Radical proponents of RpureS single address space claim that protection is orthogonal to addressing, which is true. However, due to the lack of hardware mechanisms to enforce protection rules, and to the distributed environment, the single space is in fact implemented by the co-operation of multiple virtual address spaces. Each protection domain is implemented by a virtual space. Another difficulty is the management of private data which implies some kind of base register addressing. Our claim in this position paper is that the management of data private to domains or threads is an intrinsic function of any distributed virtual memory system. Rather than hiding them in a single space, it is more efficient and simpler to implement these private areas at fixed locations in each virtual address space which will be dynamically bound to distinct physical locations. Hence, each address space is statically divided in two areas: a common area which is managed as a single address space, and a private area. Such a system combines the advantages of Opal-like systems concerning static addressing and linking, and those of classical virtual memory systems concerning the selection of local data. The remainder of this paper is organized as follows. Section 2 gives an argument for the use of private data, and shows that they can be implemented at low cost. Section 3 outlines a proposal in which a shared single address space for persistent data coexists with private segments for temporary data. In conclusion, this proposal is compared to previous systems. 2. THE NEED FOR PRIVATE DATA The problem we address is to implement protection models based on fine grain access control to segments as described in [Coulouris 1994] or in [Hagimont 1994]. In such models, the rights are expressed in terms of the segment entry-points that can be invoked in a particular protection domain. The same segment can be attached to several protection domains with different rights. If the system is unable to associate with a segment private data attached to a proP tection domain, it must trap every call to a segment entry-point. Such a mechanism is quite unrealistic, so the supporters of pure single virtual memory leave the responP sibility of fine grain protection to the run time systems of strongly typed languages. With private data the solution is quite straightforward and can be implemented at low additional cost. All the calls to a segment entry-point, within the same domain, are made indirectly through a table, the virtual entry-points table (VEP) whose entries contain the addresses of the different procedure entry-points in the segments. The VEP is built when the segment is attached (implicitly or explicitly) to the domain, using the capability on the segment owned by the domain. Entries in the table corresponding to entry-points not authorized in the domain are filled with the address of a protection violation error routine. The VEP is at the same address in all the protection domains where the segment is attached. The VEP address and the segment address are both computed at the segment creation, and will remain the same during the lifetime of the segment. A pointer to the VEP is simply located in the object value, as is the pointer to the virtual function table in most implementations of C++. 3. A PROPOSAL FOR SIRAC Project SIRAC (Systeme Informatique Reparti pour Applications Cooperatives) aims at providing a distributed environment for co-operative work. The applications are written in a high level object oriented language such as C++ or Guide. The objects are persistent and distributed. The system is partitioned into cells connected by a metropolitan or wide area network, each cell is composed of a set of homogeneous stations connected by a high speed (generally local) network. We require that the machines in a cell have a 64 bit address architecture. The lowest layer implements a distributed virtual memory including a shared area managed as a single address space common to all threads and protection domains in the cell, and a set of private areas, one for each domain. All these private areas are accessed in the same address range, the private area for a domain being selected by the dynamic address translation facility. Each private area may in turn be split in an area global to the domain and local areas for threads running in the domain. A lock manager and a checkpointing facility are also provided at this level. These facilities are intended to support a database management system. On top of this memory is implemented a coarse grain segment model with a protection scheme based on software capabilities (cf. section 2). For efficiency purposes, the access rights for a segment in a domain are only checked at the first reference to the segment in that domain; afterwards, a processor accesses the segment by its virtual address. 4. CONCLUSION In the late sixties, some of the ideas developed here were explored in the context of small address spaces (see for example [Btourn 1970] or [Watson 1970]). In Esope, a virtual space was associated with a multi-thread process and divided in two parts for private and public data. The size of the space dictated that the shared part contained one program at a time, which resolved the linking problems. This approach became obsolete with the appearance of segmented machines (Multics) and later of capability machines (Hydra). It gains a renewed interest with wide address space architectures, in which it is realistic to manage the shared part as a single address space with all of its advantages. Within the Sirac project, we intend to provide this kind of distributed virtual space at the lowest level and to implement on top of it a fine grain protection scheme as outlined in section 2. REFERENCES Betourne, C., Ferrie, J., Kaiser, C., Krakowiak, S. and Mossiere, J. (1970). "Process Management and Resource Sharing in the Multiaccess System ESOPE." Communications of the ACM 13(12) Chase, J. S., Levy, H. M., Feeley, M. J. and Lazowska, E. D. (1994). Sharing and Protection in a Single Address Space Operating System. University of Washington. Coulouris, G. and Dollimore, J. (1994). Security requirements for cooperative work: a model and its system implications. Department of Computer Science, Queen Mary and Westfield College, University of London (position paper submitted to Sixth European SIGOPS Workshop) Hagimont, D. (1994). Protection in the Guide object-oriented distributed system. ECOOP94, Bologna, Italia Heiser, G., Elphinstone, K., Russell, S. and Hellestrand, G. R. (1993). A Distributed Single Address-Space Operating System Supporting Persistence. School of Computer Science and Engineering, The University of New South Wales. Murray, K., Wilkinson, T., Osmon, P., Saulsbury, A., Stiemerling, T. and Kelly, P. (1993). Design and Implementation of an Object-Oriented 64-bit Single Address Space Microkernel. Microkernels and Other Kernel Architectures, San Diego, California, Usenix association. Watson, R. W. (1970). Timesharing system design principles. Mc Graw-Hill. _______________ END OF PAPER ______________________________________________ ---- Frederic Saunier ------------------------------------------- Snail: Unite Mixte BULL-IMAG email: Frederic.Saunier@imag.fr 2, avenue de Vignate Z.I. Mayencin Tel: +33 76 63 48 53 38610 GIERES - FRANCE Fax: +33 76 54 76 15 ------------------------------------------------------------------ From levy@cs.washington.edu Mon Apr 25 11:46:58 1994 To: sasos@cs.dartmouth.edu, Xavier.Rousset@imag.fr, Jacques.Mossiere@imag.fr Subject: Re: Position paper (Was: Some thoughts on OOP and SASOS) In-reply-to: Your message of "Fri, 22 Apr 1994 18:07:04 +0200." <9404221607.AA23539@guadalupe.imag.fr> Date: Fri, 22 Apr 1994 14:05:04 PDT From: Hank Levy Status: RO It seems like the real question is whether you really really want to have context-dependent addressing. We talked (i.e., fought) about the advantages and disadvantages of unique address interpretation for a year when Opal began. Yes, you could definitely have pages that have context-dependent interpretation, as you propose, and in fact, that would solve some problems that we're struggling with right now for Opal. Overall, though, the reason to not "muddy the water" with context-dependent addressing is that: -- once you do this, you can *never* change your mind about what's shared and what's private -- you would have to know whether a pointer is to private space or shared space before passing that pointer to somebody else -- you lose the hardware advantages of the single address space structure (as described in the paper on protection for SASOS we published in the last ASPLOS) hank From Preston.F.Crow@Dartmouth.EDU Mon Apr 25 11:46:59 1994 Date: 25 Apr 94 11:08:57 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: SASOS list archive To: sasos@cs.dartmouth.edu Status: RO As of this message (if everything works right) we are now archiving this mailing list. You can retrieve it via FTP from cs.dartmouth.edu in the file /pub/sasos/list-archive. We have all the old messages saved and we will eventually place them into an archive file, as well. --PC From dfk@cs.dartmouth.edu Mon Apr 25 11:09:03 1994 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id LAA18931; Mon, 25 Apr 1994 11:09:03 -0400 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.8.1+DND/4.5HUB) id LAA24762; Mon, 25 Apr 1994 11:09:02 -0400 Message-id: <3248716@dancer.Dartmouth.EDU> Date: 25 Apr 94 11:08:57 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: SASOS list archive To: sasos@cs.dartmouth.edu As of this message (if everything works right) we are now archiving this mailing list. You can retrieve it via FTP from cs.dartmouth.edu in the file /pub/sasos/list-archive. We have all the old messages saved and we will eventually place them into an archive file, as well. --PC From dfk@cs.dartmouth.edu Mon Apr 25 12:04:41 1994 Received: from hplms26.hpl.hp.com by cs.dartmouth.edu (8.6.5/4.2) id MAA20014; Mon, 25 Apr 1994 12:04:39 -0400 From: fouts@bozeman.hpl.hp.com Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA22397; Mon, 25 Apr 1994 09:05:37 -0700 Received: from bozeman.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA11705; Mon, 25 Apr 1994 09:04:18 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+IOS 3.14) id AA18083; Mon, 25 Apr 1994 09:06:26 -0700 Date: Mon, 25 Apr 1994 09:06:26 -0700 Message-Id: <9404251606.AA18083@bozeman.hpl.hp.com> To: sasos@cs.dartmouth.edu, Xavier.Rousset@imag.fr, Jacques.Mossiere@imag.fr Cc: sasos@cs.dartmouth.edu In-Reply-To: <9404221607.AA23539@guadalupe.imag.fr> (saunier@mururoa.imag.fr) Subject: Re: Position paper (Was: Some thoughts on OOP and SASOS) Reply-To: Martin Fouts >>>>> "Saunier" == Frederic Saunier writes: I have a small technical nit to pick with your paper. You say: >> [...] The main challenge is >> probably the design and implementation of a protection >> scheme to limit the access rights of each thread or >> application running in the single space. Radical proponents >> of RpureS single address space claim that protection is >> orthogonal to addressing, which is true. However, due to the >> lack of hardware mechanisms to enforce protection rules, and >> to the distributed environment, the single space is in fact >> implemented by the co-operation of multiple virtual address >> spaces. Each protection domain is implemented by a virtual >> space. This is not precisely true, since modern risc architectures separate protection from address space. HP's PA-RISC, for example, supports a programming model in which protection is per page and all virtual pages are allocated from the same page table. (over simplifcation, but accurate for this purpose.) It is possible to have a single virtual address space with separate protection domains in this model. I believe from reading the architecture manuals that this is true of other recent risc architectures. Additionally, it is possible, although expensive if you are not very careful, to implement single address space systems with protection domains within the address space on traditional "vax like" two level page table machines, such as the Intel ?86 family of processors. marty From dfk@cs.dartmouth.edu Mon Apr 25 12:20:54 1994 Received: from hplms26.hpl.hp.com by cs.dartmouth.edu (8.6.5/4.2) id MAA20140; Mon, 25 Apr 1994 12:20:53 -0400 From: fouts@bozeman.hpl.hp.com Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA22595; Mon, 25 Apr 1994 09:20:39 -0700 Received: from bozeman.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA12295; Mon, 25 Apr 1994 09:19:25 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+IOS 3.14) id AA18108; Mon, 25 Apr 1994 09:21:34 -0700 Date: Mon, 25 Apr 1994 09:21:34 -0700 Message-Id: <9404251621.AA18108@bozeman.hpl.hp.com> To: gernot@vast.unsw.edu.au Cc: sasos@cs.dartmouth.edu In-Reply-To: <9404220629.AA28309@jungfrau> (message from Gernot Heiser on Fri, 22 Apr 1994 16:29:30 +1000) Subject: Re: The Mungi Manifesto Reply-To: Martin Fouts >>>>> "Gernot" == Gernot Heiser writes: This is an interesting manifesto. To keep the conversation going, I thought I'd comment on two points. 1) The manifest doesn't describe the nature of the system for which Mungi is intended. There is a significant difference in the kind of SASOS appropriate for a network of workstations and servers and the kind appropriate for a network in which disconected computing was prevelant, for example. Gernot> [...] Gernot> There are no user-visible memory hierarchies, no file system. Gernot> [...] Gernot> As there is no file system, all the secondary memory in the Gernot> system is nothing but paging store. Gernot> [...] There are two reasons these statements raise a red flag for me, both performance related. Systems tend to be more usable if the default mode does not require the user to be aware of the underlying facilities, but if it is possible for performance conscious users to be able to intereact with those facilities. This suggests that the memory hierarchy should be accessable to those who wish to achieve critical performance. Second, physical memory hierarchies are becoming quite complex, as are the demands placed on them by facilities such as multimedia. It is not unusual for a workstation to have disks with two or more performance characteristics, and servers routinely have many forms of secondary and tertiary media. A single level paging hierarchy is not an appropriate model to map onto the performance requirements of such systems, because it does not address the need to move backing store between levels, or between media of different performance charateristics within one level. marty From dfk@cs.dartmouth.edu Tue Apr 26 04:32:15 1994 Received: from conch.vast.unsw.edu.au by cs.dartmouth.edu (8.6.5/4.2) id EAA26381; Tue, 26 Apr 1994 04:32:12 -0400 Received: from miter (miter.vast.unsw.edu.au) by conch.vast.unsw.edu.au with SMTP id AA07367 (5.65c/IDA-1.4.4 for ); Tue, 26 Apr 1994 18:32:00 +1000 From: Steve Russell Received: by miter (5.0/client-1.3) id AA04430; Tue, 26 Apr 94 18:31:56 EST Message-Id: <9404260831.AA04430@miter> Subject: Re: The Mungi Manifesto To: fouts@hplms2.hpl.hp.com Date: Tue, 26 Apr 1994 18:31:55 +1000 (EST) Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9404251621.AA18108@bozeman.hpl.hp.com> from "fouts@bozeman.hpl.hp.com" at Apr 25, 94 09:21:34 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1374 > 1) The manifesto doesn't describe the nature of the system for which > Mungi is intended. True. This is addressed in passing in our papers. We expect a small group of workstations/servers working in an enclave; ie, a rather conventional, small scale distrib system with an emphasis on sharing of persistent information (CAD, DBMS, etc). > Systems tend to be more usable if the default > mode does not require the user to be aware of the underlying > facilities, but if it is possible for performance conscious users to > be able to interact with those facilities. Agreed. There are times when "look how flat my memory is" is not appropriate. Accessing devices is one such case. Stream devices don't map onto memory at all well, so access is via procedures which can access the devices. High performance apps can also access the devices though. > Second, physical memory hierarchies are becoming quite complex, as are > the demands placed on them by facilities such as multimedia. Agreed again. This isn't necessarily a reason for throwing out the model, but rather an argument for better hooks for high performance systems to control what they need (now all we have to do is get you to tell us what you need :-). The same argument applies for most existing OS's, too, of course, which is why people like yourself are investigating multimedia OS's. Cheers, Steve. From dfk@cs.dartmouth.edu Tue Apr 26 09:02:43 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA27207; Tue, 26 Apr 1994 09:02:42 -0400 Message-Id: <199404261302.JAA27207@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA12749; Tue, 26 Apr 94 09:02:04 -0400 Date: Tue, 26 Apr 94 09:02:04 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: ben@london.apdg.com Cc: sasos@cs.dartmouth.edu In-Reply-To: <9404221523.AA01110@london.apdg.com> (ben@london.apdg.com) Subject: Re: Issues of naming in SASOSs I put forward an idea on this a few days ago, but no one seemed to be interested in anything but GC. I suggested that standard OO languages introduce a 2 level naming hierarchy: objects and instance variables/methods (or whatever terminology you prefer). I wondered what value there would be to extending this hierarchy to more levels... Actually, at least three languages I can think of (Modula, Ada, soon C++) have gone to a third level by introducing the notion of a namespace. From the programmer perspective, namespaces add three kinds of value: o Finer grain control over name export. o Reduced likelihood of name collision, which can be eliminated altogether given a smart linker. o Ability to do linking in terms of an object that has semantic content (the namespace) rather than just files. Once you get into multiple programs from multiple companies, however, this isn't enough anymore, and you begin to want to ensure that there is no way for another program to reference your data inadvertantly. I simply don't feel that hierarchies of objects, as seen in filesystems, are appropriate for the management of the billions of names in a SASOS, but that isn't what I am proposing here. It seems to me that this is both right and wrong. There is some embedded confusion of issues in here that are worth teasing apart: 1) The sheer size of the address space. 2) The expected number of objects, which is NOT a function of (1). 3) The size of the objects 4) The average relationship density (e.g. pointers) of the objects. I suggest that the only way you get billions of objects is for them to be relatively small, or for them to accumulate over a long period of time. In either case, they are likely to be linked into a pointer structure that is globally hierarchical, even if it is locally cyclic. The problem is to determine the proper granularities for introducing hierarchy. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Tue Apr 26 09:17:22 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA27336; Tue, 26 Apr 1994 09:17:20 -0400 Message-Id: <199404261317.JAA27336@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA14655; Tue, 26 Apr 94 09:14:17 -0400 Date: Tue, 26 Apr 94 09:14:17 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: fouts@hplms2.hpl.hp.com Cc: sasos@cs.dartmouth.edu, Xavier.Rousset@imag.fr, Jacques.Mossiere@imag.fr, sasos@cs.dartmouth.edu In-Reply-To: <9404251606.AA18083@bozeman.hpl.hp.com> (fouts@bozeman.hpl.hp.com) Subject: Re: Position paper (Was: Some thoughts on OOP and SASOS) This is not precisely true, since modern risc architectures separate protection from address space. HP's PA-RISC,... Beware generalizing from a single architecture. The HP PA RISC is a fine piece of work. It is also unorthodox in a number of ways (most of them smart). It's not yet clear how many of these will filter back into mainstream computer architecture. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Tue Apr 26 09:25:13 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA27414; Tue, 26 Apr 1994 09:25:12 -0400 Message-Id: <199404261325.JAA27414@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA14657; Tue, 26 Apr 94 09:22:08 -0400 Date: Tue, 26 Apr 94 09:22:08 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: fouts@hplms2.hpl.hp.com Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9404251621.AA18108@bozeman.hpl.hp.com> (fouts@bozeman.hpl.hp.com) Subject: Re: The Mungi Manifesto Gernot> [...] Gernot> There are no user-visible memory hierarchies, no file system. Gernot> [...] Gernot> As there is no file system, all the secondary memory in the Gernot> system is nothing but paging store. Gernot> [...] There are two reasons these statements raise a red flag for me, both performance related. Systems tend to be more usable if the default mode does not require the user to be aware of the underlying facilities... Two issues are getting confused here: o The namespace as seen by the trusted computing base. o The namespace as seen by the user. The operating system, generally speaking, has no need of human readable names. There are a lot of reasons to remove them, not the least of which is internationalization. The user, on the other hand, needs to be able to speak in user terms, which argues for something morally akin to directories (catalogs). The point is that directories do not need to be implemented by the operating system, and there should be no requirement that User A and User B even see the same *kind* of namespace. For example, when I log in I may want to see a UNIX-like system. When you log in you may want to see a Windows-NT like system. There is no reason that the operating system cannot supply both successfully. This suggests that the memory hierarchy should be accessable to those who wish to achieve critical performance. Typically, the underlying flat namespace is part of the security architecture, which raises some problems, but in general you are right. There are applications that need to know things about the underlying memory architecture. Consider that a WORM drive has fundamentally different performance from a (magnetic) disk drive. The catch here is in object identity. Given a memory hierarchy, one needs to be able to migrate objects from fast store to slow store without changing their system-level names. This requirement seriously impedes all of the obvious capability naming systems by requiring a name translation layer that you can otherwise get away without. Second, physical memory hierarchies are becoming quite complex, as are the demands placed on them by facilities such as multimedia. It is not unusual for a workstation to have disks with two or more performance characteristics, and servers routinely have many forms of secondary and tertiary media. A single level paging hierarchy is not an appropriate model to map onto the performance requirements of such systems, because it does not address the need to move backing store between levels, or between media of different performance charateristics within one level. Make a distinction between levels of hierarchy and naming. A flat namespace works fine if there are mechanisms that allow a program to acquire a page with suitable characteristics by specificying the desired characteristics. The problem only gets hairy when it is later necessary to relocate that page to a different storage class. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Tue Apr 26 09:47:02 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA27665; Tue, 26 Apr 1994 09:47:02 -0400 Message-Id: <199404261347.JAA27665@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA14659; Tue, 26 Apr 94 09:41:01 -0400 Date: Tue, 26 Apr 94 09:41:01 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: sasos@cs.dartmouth.edu In-Reply-To: (message from Tim Wilkinson on Thu, 21 Apr 1994 14:00:48 +0100 (BST)) Subject: Re: Issues of naming in SASOSs Currently we are concentrating on naming all thing at the system level by address while providing a personal hierachy of symbolic names for users (built from a global hierarchy). How are other SASOS systems tackling this issue? I'm not sure how to map what follows onto an address based model, but perhaps it will spark some thoughts in people who have been thinking about this longer than I have. KeyKOS had a flat namespace for disk pages and disk nodes, each of which was named by a 48 bit unique identifier. A capability consisted of this identifier plus a 32 bit generation count plus some type information. When access to a page/node needed to be rescinded, the generation count on the object is simply incremented. If your key generation doesn't match the object generation, access is denied. Per-page generation counts were kept in an auxilliary page on permanent store. To remove the problem of generation count rollover, the system keeps all keys to an object linked in a circular chain in memory. If any key naming the object goes to disk, the generation count has to be bumped, but since objects tend to die quickly it is frequently possible to walk the key chain in core and rescind the keys that way. In the kernel, there is a table that maps contiguous ranges of keys onto disk paritions. The key actually describes the offset (in pages or nodes as appropriate) to the relevant object relative to the partition. Media can be replicated, with associated advantages in replicated I/O. On the 370, given a dual-headed disk connected to two channels, KeyKOS achieved streaming rates that utilized 195% of the single channel bandwidth. This while still doing useful work. Note that the name translation mechanism is very cheap and minimal. Capability name translation had been a big bottleneck in previous capability systems. Unfortunately this choice also eliminated some flexibility in object relocation. If I were going to rebuild it now I don't think I would do it quite this way anymore. So on to user-level naming. When a user logs in, they speak to an authorization agent that initially owns a capability to the terminal. The authorization agent maintains a table of users and their environments, and essentially splices the user into their session, which either means reconnecting them to a previously established window manager or terminal session. All processes are persistent, so creating an initial session is actually an uncommon special case (which can be handled when the user account is first created). Essentially you get back you window system as you left it. One of the parts of your environment is probably an operating system service provider (what the IBM Workplace Shell might call a personality module). This subsystem (which may consist of multiple cooperating processes) implements whatever namespace is appropriate to your environment. For example, in the prototype UNIX implementation, there was a process that implemented a UNIX-style file system name space. In the KeyKOS approach, *all* user-visible naming is context dependent, but the same object can be made accessable from multiple user namespaces through suitable use of namespaces. Also, multiple interface versions can be supported easily, so it possible to run multiple revisions of an operating system side by side. The latter is a compelling reason to have some capacity for context dependent addressing. It is possible for a single KeyKOS microkernel to execute two logically independent KeyKOS systems on a single processor, without either system being aware of the other. This is essential if you want to do things like hot standby. Hope some of that is useful. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Tue Apr 26 13:35:26 1994 Received: from hplms26.hpl.hp.com by cs.dartmouth.edu (8.6.5/4.2) id NAA29285; Tue, 26 Apr 1994 13:35:25 -0400 From: fouts@bozeman.hpl.hp.com Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA03622; Tue, 26 Apr 1994 10:36:18 -0700 Received: from bozeman.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA13088; Tue, 26 Apr 1994 10:35:03 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+IOS 3.14) id AA18646; Tue, 26 Apr 1994 10:37:15 -0700 Date: Tue, 26 Apr 1994 10:37:15 -0700 Message-Id: <9404261737.AA18646@bozeman.hpl.hp.com> To: smr@vast.unsw.edu.au Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9404260831.AA04430@miter> (message from Steve Russell on Tue, 26 Apr 1994 18:31:55 +1000 (EST)) Subject: Re: The Mungi Manifesto Reply-To: Martin Fouts >>>>> "Steve" == Steve Russell writes: >> [Q:...] Steve> [Answer...] Thanks for the follow up. Steve> Agreed again. This isn't necessarily a reason for throwing out Steve> the model, but rather an argument for better hooks for high Steve> performance systems to control what they need (now all we have Steve> to do is get you to tell us what you need :-). The same Steve> argument applies for most existing OS's, too, of course, which Steve> is why people like yourself are investigating multimedia OS's. I didn't mean throw the model out, but rather refine it to explictly include a model for the physical memory hierarchy. It turns out that when we did the paper design of Brevix we found that being explict about performance hooks made a big difference to the semantics we provided by default and changed the way in which we would have partitioned the system. This is especially apparent in the interaction between vm and the various physical hierarchy managers. BTW, not to give the wrong impression, I'm not looking multimedia OSs these days, I'm sort of in the same position you are. The mm people, as well as the telecoms types are among my potential customers for Brevix, which is not a SASOS. marty From dfk@cs.dartmouth.edu Tue Apr 26 15:30:11 1994 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id PAA00121; Tue, 26 Apr 1994 15:30:10 -0400 From: fouts@bozeman.hpl.hp.com Received: from hplms26.hpl.hp.com by dartvax.dartmouth.edu (8.6.8.1+DND/4.5HUB) id PAA24979; Tue, 26 Apr 1994 15:30:08 -0400 Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA04998; Tue, 26 Apr 1994 12:31:17 -0700 Received: from bozeman.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA17620; Tue, 26 Apr 1994 12:30:02 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+IOS 3.14) id AA18727; Tue, 26 Apr 1994 12:32:14 -0700 Date: Tue, 26 Apr 1994 12:32:14 -0700 Message-Id: <9404261932.AA18727@bozeman.hpl.hp.com> To: shap@viper.cis.upenn.edu Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9404261326.AA01461@hplms26.hpl.hp.com> (shap@viper.cis.upenn.edu) Subject: Namespaces (was Re: The Mungi Manifesto) Reply-To: Martin Fouts >>>>> "Jonathan" == Jonathan Shapiro writes: Jonathan> Two issues are getting confused here: Jonathan> o The namespace as seen by the trusted computing base. Jonathan> o The namespace as seen by the user. I agree. Jonathan> The operating system, generally speaking, has no need of Jonathan> human readable names. There are a lot of reasons to remove Jonathan> them, not the least of which is internationalization. You are right. An interesting question is how many different name spaces does the operating system need? Jonathan> [...] Jonathan> The point is that directories do Jonathan> not need to be implemented by the operating system, and Jonathan> there should be no requirement that User A and User B even Jonathan> see the same *kind* of namespace. Yes. (Ignoring a definitional issue about what you mean by "the operating system.") In Brevix, we provided a separate facility which manages user visible name spaces. (in the form of trees) Any resource manager which wishes to allow users to name the resources it manages may take advantage of this facility, which uses a recursive descent mechanism for translating user names to manager/resource-name pairs. It is entirely up to the manager to assign semantics to the resource-name, which is guarenteed to be a unique token. Thus, we have a two step translation from a user name to an object, where the owner of the object is responsible for the translation from the resource-name to an appropriate internal name. For many resources, a virtual address is not an appropriate internal name; often an ordinal works better. Jonathan> [Security discussion elided ... ] Jonathan> >> [ Description of typical media hierarchy...] Jonathan> Make a distinction between levels of hierarchy and naming. Yes. Sorry I wasn't clear. In the elided paragraph, I was only talking about storage hierarchy, which is quite different than naming, unless you make the mistake of encoding the location of an object in its name. Jonathan> A flat namespace works fine if there are mechanisms that Jonathan> allow a program to acquire a page with suitable Jonathan> characteristics by specificying the desired Jonathan> characteristics. The problem only gets hairy when it is Jonathan> later necessary to relocate that page to a different Jonathan> storage class. Here, I assume "flat namespace" means the system's internal name space for the resource "virtual memory." In this context I agree with you. marty From dfk@cs.dartmouth.edu Tue Apr 26 17:02:45 1994 Received: from swan.cl.cam.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id RAA00705; Tue, 26 Apr 1994 17:02:44 -0400 From: Eoin.Hyden@cl.cam.ac.uk Received: from lachne.cl.cam.ac.uk (user eah (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Tue, 26 Apr 1994 22:02:24 +0100 To: sasos@cs.dartmouth.edu Subject: Re: Issues of naming in SASOSs In-reply-to: Your message of Tue, 26 Apr 94 09:02:04 -0400. <199404261302.JAA27207@cs.dartmouth.edu> Date: Tue, 26 Apr 94 22:02:04 +0100 X-Mts: smtp Message-ID: <"swan.cl.cam.:215200:940426210231"@cl.cam.ac.uk> [stuff deltedted] | From the programmer perspective, namespaces add three kinds of value: [stuff deltedted] | o Reduced likelihood of name collision, which can be eliminated | altogether given a smart linker. Is this a DWIM linker? Eoin From dfk@cs.dartmouth.edu Wed Apr 27 09:53:51 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA04870; Wed, 27 Apr 1994 09:53:50 -0400 Message-Id: <199404271353.JAA04870@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA18124; Wed, 27 Apr 94 09:50:45 -0400 Date: Wed, 27 Apr 94 09:50:45 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: fouts@hplms2.hpl.hp.com Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9404261932.AA18727@bozeman.hpl.hp.com> (fouts@bozeman.hpl.hp.com) Subject: Re: Namespaces (was Re: The Mungi Manifesto) Jonathan> The operating system, generally speaking, has no need of Jonathan> human readable names. There are a lot of reasons to remove Jonathan> them, not the least of which is internationalization. You are right. An interesting question is how many different name spaces does the operating system need? There are significant simplifications if you the operating system can implement exactly one object namespace and impose the protection architecture on that namespace. Certainly KeyKOS worked fine with a single storage namespace. The only case I can think of where the KeyKOS system implemented multiple name spaces was when a single kernel ran two logically disjoint systems in a hot-failover mode. In that case, disjoint namespaces is exactly what you want. At the moment, I don't quite see how a SASOS could run multiple OS versions simultaneously. I should add something about that: KeyKOS was not SASOS in the sense that this group seems to use the term. KeyKOS had a single flat name space of capabilities for persistent storage, but every domain can in principle have it's own memory address space. The usual practice was for the per-domain address space to be private. Counterexamples typically involved threads. Jonathan> [...] Jonathan> The point is that directories do Jonathan> not need to be implemented by the operating system, and Jonathan> there should be no requirement that User A and User B even Jonathan> see the same *kind* of namespace. Yes. (Ignoring a definitional issue about what you mean by "the operating system.") More precisely, I should have said that directories do not need to be implemented by the Privileged Computing Base (the PCB is the portion of the system that runs in supervisor mode, by analogy to Trusted Computing Base). One thing to avoid is to build any name manager anywhere that you assume will be universally used. The semantics of "what's a name" depend on what conventions the user-visible OS has, and this is something you will want to be able to change over time. Here, I assume "flat namespace" means the system's internal name space for the resource "virtual memory." In this context I agree with you. In the context of KeyKOS, the flat name space was for persistent pages and persistent nodes (the latter hold capabilities in the same way that pages hold data). Strictly speaking, KeyKOS had a split addressing scheme (the capability embeds a type byte which selects which space we look at), but this was probably a design flaw. Jonathan> Make a distinction between levels of [storage] hierarchy Jonathan> and naming. Yes. Sorry I wasn't clear. In the elided paragraph, I was only talking about storage hierarchy, which is quite different than naming, unless you make the mistake of encoding the location of an object in its name. I agree that you want referential transparency (I don't have to know where the object is stored to use its capability to get it). I'm not convinced that you want location transparency. Storage hierarchies require that locations not be wholly transparent. Actually, we can divide storage hierarchies into two cases: o Hierarchies implemented as multilayered cache, in which there is conceptually a single level of storage some of which is faster than the rest. This layering need only be exposed if you are concerned about real-time behavior, and does not require that objects be relocatable. o Hierarchies wherein it is appropriate for the application to explicitly manage the latency that is acceptable for a particular stored object. This requires both that the storage hierarchy be exposed and that objects be relocatable from one logical storage location to another. THIS is the case that breaks if your capabilities embed object location information. In KeyKOS, it was possible to migrate a contiguous range of objects into a different partition, but not possible to migrate a particular object. There's a tradeoff here, and I've never been satisfied with any of the solutions. If your naming scheme encodes location, it can be implemented efficiently, and the name translation tables seldom need to be updated. This is good, as it essentially eliminates the place where the system is most vulnerable to unplanned outage. In addition, a location-sensitive naming scheme simplifies low level system debugging. Most important, a location-sensitive scheme eliminates the need for the PCB to do storage allocation. If your naming scheme is location transparent, then you need to manage some fairly tricky tables. These tables were a performance bottleneck in most of the early capability systems, and they introduce the need for the system to perform dynamic reallocation of the disk store. This is a major source of vulnerability (the algorithms are simply hard to do if you require that they be interruptable by a power outage at any point). I wonder how many nontransparent storage hierarchy problems can't in fact be modeled as cacheing-style hierarchies. If they can, it is sufficient to be able to specify the storage class when you create the object, and migrate entire partitions. Jonathan From dfk@cs.dartmouth.edu Wed Apr 27 17:39:32 1994 Received: from hplms26.hpl.hp.com by cs.dartmouth.edu (8.6.5/4.2) id RAA02117; Wed, 27 Apr 1994 17:39:30 -0400 From: fouts@bozeman.hpl.hp.com Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA17024; Wed, 27 Apr 1994 14:40:30 -0700 Received: from bozeman.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA24750; Wed, 27 Apr 1994 14:39:14 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+IOS 3.14) id AA19541; Wed, 27 Apr 1994 14:41:27 -0700 Date: Wed, 27 Apr 1994 14:41:27 -0700 Message-Id: <9404272141.AA19541@bozeman.hpl.hp.com> To: shap@viper.cis.upenn.edu Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9404271355.AA12123@hplms26.hpl.hp.com> (shap@viper.cis.upenn.edu) Subject: Re: Namespaces (was Re: The Mungi Manifesto) Reply-To: Martin Fouts >>>>> "Jonathan" == Jonathan Shapiro writes: Jonathan> [...] Jonathan> There are significant simplifications if you the operating Jonathan> system can implement exactly one object namespace and Jonathan> impose the protection architecture on that namespace. I'm not sure I understand the simplification. In Brevix we recognized that protection requires a triple. There is the object operated on, the operation to be performed and the agent performing the operation. Each of these things need to be named and the protect check made "in effect" at the time the operation is attempted. (Clearly, there are optimizations which allow precomputation, and transitive operations the success of which ensure the ability to perform other operations, such as open-for-write ensuring the ability to write.) Although I can envision a naming scheme which maps the apparent names of agents to the address of data structures representing those agents, I believe that there are simpler schemes for the os to internally name agents. Similar comments hold for operations. Jonathan> The only case I can think of where the KeyKOS system Jonathan> implemented multiple name spaces was when a single kernel Jonathan> ran two logically disjoint systems in a hot-failover mode. Jonathan> In that case, disjoint namespaces is exactly what you want. Jonathan> At the moment, I don't quite see how a SASOS could run Jonathan> multiple OS versions simultaneously. I'll pass. (;-) By the way, it seems you are implying that KeyKOS has an architecture similar to IBM's VM. As I understand VM it requires hardware assists to revector I/O operations transparently. I assume that KeyKOS makes the assumption that client OSes are written to use a well behaved interface to perform I/O, rather than depending on a hardware mechanism. Is this correct? Jonathan> [Description of KeyKOS address space elided...] Jonathan> More precisely, I should have said that directories do not Jonathan> need to be implemented by the Privileged Computing Base Jonathan> (the PCB is the portion of the system that runs in Jonathan> supervisor mode, by analogy to Trusted Computing Base). Yes. Actually, very little needs to be implemented by th PCB. In Brevix, we got it down to operations which require hardware privilige, page table management, and protection domain interface crossings. We would have implemented I/O operations in supervisor mode for efficiency, but did not strictly need to. Again, part of this was due to the flexibility of the the PA-RISC protection model. Jonathan> One thing to avoid is to build any name manager anywhere Jonathan> that you assume will be universally used. The semantics of Jonathan> "what's a name" depend on what conventions the user-visible Jonathan> OS has, and this is something you will want to be able to Jonathan> change over time. I'd be interested in having the above expanded. I belive you trade user visible consistency in naming away when you attempt this level of flexibility, and I'm not sure reserving the right to change the naming scheme at a later date is a sufficient reason for giving up naming consistency, so I've probably missed something here. Jonathan> [...] Jonathan> I agree that you want referential transparency (I don't Jonathan> have to know where the object is stored to use its Jonathan> capability to get it). I'm not convinced that you want Jonathan> location transparency. Storage hierarchies require that Jonathan> locations not be wholly transparent. There is always some customer of a system who wants location transparency. This is the customer who needs automagic migration between storage levels. For this customer we provide naming transparency. For other customers we provide mechanisms for making the location available, although we attempt to hide those mechanisms behind service-level descriptions rather than actual storage unit names. Jonathan> [...] Jonathan> I wonder how many nontransparent storage hierarchy problems Jonathan> can't in fact be modeled as cacheing-style hierarchies. If Jonathan> they can, it is sufficient to be able to specify the Jonathan> storage class when you create the object, and migrate Jonathan> entire partitions. It is not always true that the performance requirements of an object remain constant over the life of the object. In this case, you must be able to give hints to the system when the characteristics are about to change. Further, if they are likely to change for a long duration, you may want to migrate only that object from its current partition to one more appropriate for its new requirements. The classic example is that of file aging. Once a file has reached a certain age without being touched, the odds are very good that it should migrate to a higher latency lower cost level of the storage hierarchy. marty From dfk@cs.dartmouth.edu Fri Apr 29 04:02:11 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id EAA11681; Fri, 29 Apr 1994 04:02:08 -0400 From: Kevin A Murray Date: Fri, 29 Apr 1994 09:06:42 +0100 Message-Id: <25229.199404290806@barney.cs.city.ac.uk> To: sasos@cs.dartmouth.edu Subject: Multiple DSM policies in SASOS Since Angel, City's Sasos, is intended to run on a system without, necessarily, real shared memory it uses DSM. Currently Angel's DSM only implements a strict coherence model. There are plans to allow multiple coherence models to exist with the single address space, albeit it with a maximum of one model per object. Have any other systems had experience of providing multiple models within a SASOS? If so how has this been done, and what have the experiences been. Alternatively what ideas do people have on this area. This sort of follows on from the idea of trying to support the model and means most appropriate to the needs of the application. Kevin From dfk@cs.dartmouth.edu Fri Apr 29 04:03:17 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id EAA11695; Fri, 29 Apr 1994 04:03:15 -0400 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 29 Apr 1994 09:07:48 +0100 Date: Fri, 29 Apr 1994 09:00:33 +0100 (BST) From: Tim Wilkinson Subject: Re: Issues of naming in SASOSs To: Single Address Space Operating Systems In-Reply-To: <16300.199404261353@barney.cs.city.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 26 Apr 1994, Jonathan Shapiro wrote: > So on to user-level naming. > > When a user logs in, they speak to an authorization agent that > initially owns a capability to the terminal. The authorization agent > maintains a table of users and their environments, and essentially > splices the user into their session, which either means reconnecting > them to a previously established window manager or terminal session. > All processes are persistent, so creating an initial session is > actually an uncommon special case (which can be handled when the user > account is first created). Essentially you get back you window system > as you left it. This kind of persistence has always bothered me and it is something we considered for Angel but have not pursued (on religious grounds I suspect). When everything runs okay and there are no problems it sounds great, but when things go wrong or services need to be replaced doesn't this cause problems - what about other persistent programs using replaced services which have none of the originals state. Admittedly you could hold this state externally from the service but this forces improved services to be backwards compatible not only in its interface, which is reasonable, but in the way it holds its state, which is not. > One of the parts of your environment is probably an operating system > service provider (what the IBM Workplace Shell might call a > personality module). This subsystem (which may consist of multiple > cooperating processes) implements whatever namespace is appropriate to > your environment. For example, in the prototype UNIX implementation, > there was a process that implemented a UNIX-style file system name > space. Why do I sometime feel everyone is sitting on the fence when it comes to naming things. Since microkernels became vogue all you ever seem to here is "you can use a server to provide any kind of naming you like" or words to that effect. This of course answer nothing. Okay, so what we do here it no different but I do think that there must be more radical naming schemes which could be implemented. I'd like to try and do something graphically, possibly in the realm of Gibson's cyberspace ideas where positions of objects in the space are used to name them. Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From dfk@cs.dartmouth.edu Fri Apr 29 04:44:22 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id EAA11803; Fri, 29 Apr 1994 04:44:20 -0400 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 29 Apr 1994 09:48:52 +0100 Date: Fri, 29 Apr 1994 09:41:36 +0100 (BST) From: Tim Wilkinson Subject: Re: The Mungi Manifesto To: Single Address Space Operating Systems In-Reply-To: <199404261325.JAA27414@cs.dartmouth.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 26 Apr 1994, Jonathan Shapiro wrote: > Two issues are getting confused here: > > o The namespace as seen by the trusted computing base. > o The namespace as seen by the user. > > The operating system, generally speaking, has no need of human > readable names. There are a lot of reasons to remove them, not the > least of which is internationalization. I wonder how true this actually is. There are plenty of examples where operating systems needs "well known" names inorder to tie themselves together and operate at all. This can range from well defined ports (such as used in Ameoba and Meshix) to well known traps numbers (BSD, SysV). Now perhaps people do not considered these "human readable names" but so far as I can see they consititute a well defined namespace. > The user, on the other hand, needs to be able to speak in user terms, > which argues for something morally akin to directories (catalogs). > The point is that directories do not need to be implemented by the > operating system, and there should be no requirement that User A and > User B even see the same *kind* of namespace. For example, when I log > in I may want to see a UNIX-like system. When you log in you may want > to see a Windows-NT like system. There is no reason that the > operating system cannot supply both successfully. Which brings us round to the problem of inter-operability between these namespaces and whether there is any or not. For something like UNIX and Windows-NT, which both base their filesystem layouts on similar constructs, there is no reason why this cannot be done. Indeed, the VNODE stuff available in lots of UNIX systems handles this kind of problem. However it radically different alternative were also to be used which did not map into a hierarchical(?) name structure, what then. And what about the poor operating system services, which naming scheme do they use and understand or are certain services only available in certain environment despite the fact that many share obvious commonality. So, perhaps you might want to support lots of different naming schemes depending on what environment you're planning to run, but ultimately you've got to communicate with other entities which might not be in your envionment. To do this you have to agree some common scheme (esperanto?) otherwise your envionments become isolated. Perhaps you want this but it seems a bit of a waste to me. Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From dfk@cs.dartmouth.edu Fri Apr 29 15:03:16 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id PAA14812; Fri, 29 Apr 1994 15:03:15 -0400 Message-Id: <199404291903.PAA14812@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA23680; Fri, 29 Apr 94 15:02:35 -0400 Date: Fri, 29 Apr 94 15:02:35 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: sasos@cs.dartmouth.edu In-Reply-To: (message from Tim Wilkinson on Fri, 29 Apr 1994 09:41:36 +0100 (BST)) Subject: Re: The Mungi Manifesto > The operating system, generally speaking, has no need of human > readable names. There are a lot of reasons to remove them, not the > least of which is internationalization. I wonder how true this actually is. There are plenty of examples where operating systems needs "well known" names inorder to tie themselves together and operate at all. This can range from well defined ports (such as used in Ameoba and Meshix) to well known traps numbers (BSD, SysV). Now perhaps people do not considered these "human readable names" but so far as I can see they consititute a well defined namespace. They are certainly a well defined namespace. What I was trying to get at was that embedding text of any kind in the OS tends to lead to nation-specific resource lists or some such. Doesn't really matter if the text in question is a well-known root of a namespace or an error string. > The user, on the other hand, needs to be able to speak in user terms, > which argues for something morally akin to directories (catalogs). > The point is that directories do not need to be implemented by the > operating system, and there should be no requirement that User A and > User B even see the same *kind* of namespace. For example, when I log > in I may want to see a UNIX-like system. When you log in you may want > to see a Windows-NT like system. There is no reason that the > operating system cannot supply both successfully. Which brings us round to the problem of inter-operability between these namespaces and whether there is any or not. For something like UNIX and Windows-NT, which both base their filesystem layouts on similar constructs, there is no reason why this cannot be done. Indeed, the VNODE stuff available in lots of UNIX systems handles this kind of problem. However it radically different alternative were also to be used which did not map into a hierarchical(?) name structure, what then. And what about the poor operating system services, which naming scheme do they use and understand or are certain services only available in certain environment despite the fact that many share obvious commonality. Hang on. You assumed that I wanted these systems to be two different views on the same data. Sometimes I do. At other times, I do not want one user to be able to know of the existence of another. That's where vnodes break down pretty badly. There is a whole space of requirements here, ranging from running two independent virtual machines to running one virtual machine with multiple interfaces. In the latter case, interoperation depends on the degree to which the underlying objects have compatible semantics. It's fairly simple to make a file object operate correctly under the combination of UNIX + Win/NT semantics. It's likewise fairly easy to make anything you get an IP connection to look shared (e.g. the window system). Things with incompatible semantics are hard. That's life. Jonathan From dfk@cs.dartmouth.edu Fri Apr 29 22:01:08 1994 Received: from june.cs.washington.edu by cs.dartmouth.edu (8.6.5/4.2) id WAA17114; Fri, 29 Apr 1994 22:01:07 -0400 Received: from localhost (localhost [127.0.0.1]) by june.cs.washington.edu (8.6.8/7.2ju) with SMTP id TAA16945 for ; Fri, 29 Apr 1994 19:01:06 -0700 Message-Id: <199404300201.TAA16945@june.cs.washington.edu> To: Single Address Space Operating Systems Subject: Extensibility In-reply-to: Your message of "Fri, 29 Apr 1994 09:00:33 BST." Date: Fri, 29 Apr 1994 19:01:05 PDT From: Jeff Chase > [Tim Wilkinson writes:] > > Why do I sometime feel everyone is sitting on the fence when it comes to > naming things. Since microkernels became vogue all you ever seem to here > is "you can use a server to provide any kind of naming you like" or words > to that effect. This of course answer nothing. You can think of it as "sitting on the fence", but you could also view it as an invitation to build whatever seems right, secure in the knowledge that you can plug it in when you're done. This is what my marketing friends call "extensibility", and they think it's goodness. It's important to figure out which pieces of the problem can be solved independently. Then leave them for other people's PhD theses -- and perhaps for discussion on other mailing lists. > [Kevin Murray writes:] > > Since Angel, City's Sasos, is intended to run on a system without, > necessarily, real shared memory it uses DSM. Currently Angel's DSM > only implements a strict coherence model. There are plans to allow > multiple coherence models to exist with the single address space, > albeit it with a maximum of one model per object. Have any other > systems had experience of providing multiple models within a SASOS? If > so how has this been done, and what have the experiences been. > Alternatively what ideas do people have on this area. Coherency is one of several features that we've chosen to make "extensible" in Opal. I tend to lean toward fine-grained mechanisms for coherency, but in general I believe that "any flavor you like" can be implemented using a runtime package and/or Mach-style external memory management, perhaps with a bit of compiler support thrown in. In other words, all the kernel really needs is a good external pager interface. I believe the same is true of recoverable updates to persistent data. - Jeff From dfk@cs.dartmouth.edu Mon May 2 10:26:18 1994 Received: from concorde.inria.fr by cs.dartmouth.edu (8.6.5/4.2) id KAA29405; Mon, 2 May 1994 10:26:16 -0400 Received: from sor.inria.fr (druuna.inria.fr [128.93.11.40]) by concorde.inria.fr (8.6.9/8.6.9) with SMTP id QAA06343; Mon, 2 May 1994 16:26:13 +0200 Received: by sor.inria.fr (4.1/client.23-dec-86) id AA13109; Mon, 2 May 94 16:26:09 +0200 Date: Mon, 2 May 94 16:26:09 +0200 Message-Id: <9405021426.AA13109@sor.inria.fr> Organization: INRIA, BP 105, F-78153 Rocquencourt Cedex, France telephone +33(1)39-63-55-11, telex 697033 F, fax +33(1)39-63-53-30 From: mjs@cs.cornell.edu Sender: shapiro@corto.inria.fr To: shap@viper.cis.upenn.edu Cc: sasos@cs.dartmouth.edu In-Reply-To: Jonathan Shapiro's message of Wed, 27 Apr 94 09:50:45 -0400 <199404271353.JAA04870@cs.dartmouth.edu> Subject: Namespaces >> Date: Wed, 27 Apr 94 09:50:45 -0400 >> From: shap@viper.cis.upenn.edu (Jonathan Shapiro) >> >> I agree that you want referential transparency (I don't have to >> know where the object is stored to use its capability to get it). >> I'm not convinced that you want location transparency. Storage >> hierarchies require that locations not be wholly transparent. I agree totally. >> There's a tradeoff here, and I've never been satisfied with any of >> the solutions. If your naming scheme encodes location, it can be >> implemented efficiently, and the name translation tables seldom >> need to be updated. [...] If your naming scheme is location >> transparent, then you need to manage some fairly tricky tables. A solution that works well is to encode location in the reference, but to forward if the location changes, and to arrange to update (i.e. short-cut) references that use the old location. See the following paper "SSP Chains: Robust, Distributed References Supporting Acyclic Garbage Collection", available by anonymous FTP: Host: ftp.inria.fr [192.93.2.54] Login: ftp Password: your own e-mail address Directory: INRIA/Projects/SOR File: SSPC:rr1799.ps.gz From dfk@cs.dartmouth.edu Mon May 2 13:27:14 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id NAA00948; Mon, 2 May 1994 13:27:14 -0400 Message-Id: <199405021727.NAA00948@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA01102; Mon, 2 May 94 13:26:35 -0400 Date: Mon, 2 May 94 13:26:35 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: mjs@cs.cornell.edu Cc: sasos@cs.dartmouth.edu In-Reply-To: <9405021426.AA13109@sor.inria.fr> (mjs@cs.cornell.edu) Subject: Re: Namespaces >> There's a tradeoff here, and I've never been satisfied with any of >> the solutions. If your naming scheme encodes location, it can be >> implemented efficiently, and the name translation tables seldom >> need to be updated. [...] If your naming scheme is location >> transparent, then you need to manage some fairly tricky tables. A solution that works well is to encode location in the reference, but to forward if the location changes, and to arrange to update (i.e. short-cut) references that use the old location. See the following paper "SSP Chains: Robust, Distributed References Supporting Acyclic Garbage Collection", available by anonymous FTP: I don't believe that such a solution scales well over either the number of nodes, network failures, or time. Over time, in particular, the originating node is likely to be obsoleted. The information will in some cases have a much longer lifespan. I'm therefore inclined to virtualize the notion of what information pool is the official "home" of a piece of information. Instead of providing a node name within the object ID, one uses a "logical database id" which is supported by a "logical database -> physical database" mapping mechanism. There are a number of address resolution mechanisms deployed today that would work reasonably well to support such a mapping in a large-scale, distributed fashion. From dfk@cs.dartmouth.edu Thu May 5 09:54:58 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA21358; Thu, 5 May 1994 09:54:55 -0400 Message-Id: <199405051354.JAA21358@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA09481; Thu, 5 May 94 09:50:58 -0400 Date: Thu, 5 May 94 09:50:58 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: fouts@hplms2.hpl.hp.com Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9404272141.AA19541@bozeman.hpl.hp.com> (fouts@bozeman.hpl.hp.com) Subject: Namespaces, authority, and location transparency Marty writes: I'm not sure I understand the simplification. In Brevix we recognized that protection requires a triple. There is the object operated on, the operation to be performed and the agent performing the operation. In an age where to an increasing degree, the agent may be a third-party intermediary that has independent identity from the end client, I wonder how long the notion of "who's asking" will be a sensible question. In short, I think you want a pair: (object, authority), where authority does not imply knowledge of the asker. Although I can envision a naming scheme which maps the apparent names of agents to the address of data structures representing those agents, I believe that there are simpler schemes for the os to internally name agents. Similar comments hold for operations. The protections need to be on something based on the object identity, not the object's human-visible name. There needs to be a layer at which every object is uniquely named. That is the layer where protections should be specified. Anything above that is user-oriented window dressing (important, but not relevant to the discussion of security). Jonathan> The only case I can think of where the KeyKOS system Jonathan> implemented multiple name spaces was when a single kernel Jonathan> ran two logically disjoint systems in a hot-failover mode. Jonathan> In that case, disjoint namespaces is exactly what you want. Jonathan> At the moment, I don't quite see how a SASOS could run Jonathan> multiple OS versions simultaneously. I'll pass. (;-) By the way, it seems you are implying that KeyKOS has an architecture similar to IBM's VM. As I understand VM it requires hardware assists to revector I/O operations transparently. I assume that KeyKOS makes the assumption that client OSes are written to use a well behaved interface to perform I/O, rather than depending on a hardware mechanism. Is this correct? In KeyKOS, only the microkernel (~50K code) has direct access to hardware devices. With a few exceptions (which I'll get to momentarily), the kernel performs a small service to packetize the interrupt data and hand the message to the appropriate user-level driver code, but in a very real sense the kernel does not service interrupts. The kernel does small amounts of buffering on asynchronous devices like TTY's - flow control and the like. Disk devices are fully virtualized - only the kernel knows what they look like (ignoring a few utilities like the disk formatter). Since the interrupts are "messagized", the client driver is ultimately not able to prove that it is talking directly to the device - it is possible to stick in a fully transparent translation layer that supports a virtual device interface. Even asynchronous devices can be virtualized in this fashion, though the virtualizer needs to be a bit more clever to pull it off. Jonathan> More precisely, I should have said that directories do not Jonathan> need to be implemented by the Privileged Computing Base Jonathan> (the PCB is the portion of the system that runs in Jonathan> supervisor mode, by analogy to Trusted Computing Base). Yes. Actually, very little needs to be implemented by th PCB. In Brevix, we got it down to operations which require hardware privilige, page table management, and protection domain interface crossings. We would have implemented I/O operations in supervisor mode for efficiency, but did not strictly need to. We debated, during the EROS effort (386 reverse engineering of KeyKOS, since abandoned), using the IO space protections to place all I/O drivers at user level, but decided not to. This would impede portability, and we wanted as much of our driver code to port as could reasonably be made to do so. Also, on the 386, the task switching time was slow enough that we were concerned about high baud rates. Since the disk structure is known only to the kernel, we couldn't push that out, and once you're done with those two the only thing left is the network and the video display. If you want to virtualize the video subsystem across multiple clients that think they "own" that hardware, it's useful to have a kernel hook to switch ownership in an orderly fashion. Jonathan> One thing to avoid is to build any name manager anywhere Jonathan> that you assume will be universally used. The semantics of Jonathan> "what's a name" depend on what conventions the user-visible Jonathan> OS has, and this is something you will want to be able to Jonathan> change over time. I'd be interested in having the above expanded. I belive you trade user visible consistency in naming away when you attempt this level of flexibility, and I'm not sure reserving the right to change the naming scheme at a later date is a sufficient reason for giving up naming consistency, so I've probably missed something here. You're proceeding on a reasonable assumption that I didn't intend. On KeyKOS, it is possible to simultaneously run UNIX and DOS and Windows (the last hasn't been done), each in its own virtual machine, none aware of the others. It is also possible, with care, to run all of the above talking to integrated file system and network services, and to honor their respective security policies as appropriate. At the KeyKOS-visible layer, however, all protections are determined by capabilities. Consistency isn't always the goal. Jonathan> I agree that you want referential transparency (I don't Jonathan> have to know where the object is stored to use its Jonathan> capability to get it). I'm not convinced that you want Jonathan> location transparency. Storage hierarchies require that Jonathan> locations not be wholly transparent. There is always some customer of a system who wants location transparency. This is the customer who needs automagic migration between storage levels. This is referential transparency, not location transparency. The fact that it is invisible from the perspective of the client code is irrelevant. There is still some layer of the system that has to know. Jonathan> I wonder how many nontransparent storage hierarchy problems Jonathan> can't in fact be modeled as cacheing-style hierarchies. If Jonathan> they can, it is sufficient to be able to specify the Jonathan> storage class when you create the object, and migrate Jonathan> entire partitions. It is not always true that the performance requirements of an object remain constant over the life of the object. In this case, you must be able to give hints to the system when the characteristics are about to change. Further, if they are likely to change for a long duration, you may want to migrate only that object from its current partition to one more appropriate for its new requirements. The classic example is that of file aging. Once a file has reached a certain age without being touched, the odds are very good that it should migrate to a higher latency lower cost level of the storage hierarchy. If an application has gone to the trouble to explicit request a promotion of service class for an object, the OS should not then demote the object without the application's consent - it violates the contract. We gave this a lot of thought in EROS in the context of multimedia. The issue at hand was how to handle locking things in core without unduly exposing the notion of a core page frame or breaking the referential transparency - KeyKOS/EROS views main memory strictly as a cache of the persistent store. The main challenge was doing this in a recoverable way after power outage. Our conclusion was that the issues of location and naming were orthogonol. Eventually, we invented a core locking mechanism as follows: 1. The kernel maintains a table with a fixed number of slots. Each slot can hold the name of an object that is to be kept in core. In KeyKOS there are only two object types, and all objects of a particular type have the same size, which simplifies things some. 2. A process may own a capability that grants it the right to fill one of the slots. It may fill the slot with a capability that grants it no authority to the core-locked object (you want to core lock a page you cannot read, that's your business). If necessary, the object will be faulted into core, though the process requesting that the object be locked may elect not to block for this. 3. The right to a slot can be rescinded through the usual KeyKOS capability rescind mechanism. 4. On restart/recovery, the system will core lock all locked pages before allowing anything to run - this is necessary to allow real time subsystems that need to do real-world recovery to depend on timing for the recovery prototol. 5. The core lock table itself is checkpointed to allow recovery. 6. When a core-locked page is checkpointed, a copy is made. This precludes a process blocking because of disk delays in checkpoint. There's more detail to describe the full scheme, but that should be good enough for now. There is an issue if enough physical memory has been removed that the system is unable to honor all core locks. We never resolved what should be done under these conditions. Jonathan From dfk@cs.dartmouth.edu Thu May 5 12:18:49 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id MAA22215; Thu, 5 May 1994 12:18:44 -0400 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Thu, 5 May 1994 17:23:20 +0100 Date: Thu, 5 May 1994 17:18:37 +0100 (BST) From: Tim Wilkinson Subject: Re: Sharing namespaces To: Single Address Space Operating Systems In-Reply-To: <8957.199404291907@barney.cs.city.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 29 Apr 1994, Jonathan Shapiro wrote: > Which brings us round to the problem of inter-operability between these > namespaces and whether there is any or not. ......... > > Hang on. You assumed that I wanted these systems to be two different > views on the same data. Sometimes I do. At other times, I do not > want one user to be able to know of the existence of another. That's > where vnodes break down pretty badly. There is a whole space of > requirements here, ranging from running two independent virtual > machines to running one virtual machine with multiple interfaces. In > the latter case, interoperation depends on the degree to which the > underlying objects have compatible semantics. It's fairly simple to > make a file object operate correctly under the combination of UNIX + > Win/NT semantics. It's likewise fairly easy to make anything you get > an IP connection to look shared (e.g. the window system). Things with > incompatible semantics are hard. That's life. Okay, perhaps I'm assuming I want multiple systems to interact but it does seem to be something of a one way decission to me. If they can, you can always not do it, it they can't you can never do it -- if you decide it's not possible, your stuffed if you change your mind. As for incompatible sematics - well that's the problem your trying to solve isn't it? You can take the Plan9 view (everythings a filesystem) or perhaps view everything as an object (with a core set of interfaces perhaps). Anyhow, ignoring the difficulties of incompatible semantics for the moment and considering different environments views on similar services (networking for example), it seems useful, possibly essential, for sharing to occur. Consider a TCP/IP interface. Multiple environments MUST share the ports correctly otherwise bad things will happen. You need to provide some underlying system for naming inorder for different environment to coordinate this. A human readable naming scheme at this level (not the kernel level) seems essential else you end up coding weird magic cookies into your servers to allow the necessary coordination to take place. To sum up, I think an underlying naming scheme is required on any system which proposes to support multiple environments. They can choose to provide whatever above this but there must be a 'native' to hang this all on. Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From dfk@cs.dartmouth.edu Thu May 5 12:29:29 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id MAA22296; Thu, 5 May 1994 12:29:26 -0400 Received: from wilma.cs.city.ac.uk by barney.cs.city.ac.uk; Thu, 5 May 1994 17:34:03 +0100 Date: Thu, 5 May 1994 17:29:20 +0100 (BST) From: Tim Wilkinson Subject: Re: Extensibility To: Single Address Space Operating Systems In-Reply-To: <199404300201.TAA16945@june.cs.washington.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 29 Apr 1994, Jeff Chase wrote: > > [Tim Wilkinson writes:] > > > > Why do I sometime feel everyone is sitting on the fence when it comes to > > naming things. Since microkernels became vogue all you ever seem to here > > is "you can use a server to provide any kind of naming you like" or words > > to that effect. This of course answer nothing. > > You can think of it as "sitting on the fence", but you could also view > it as an invitation to build whatever seems right, secure in the knowledge > that you can plug it in when you're done. This is what my marketing > friends call "extensibility", and they think it's goodness. > > It's important to figure out which pieces of the problem can be solved > independently. Then leave them for other people's PhD theses -- and > perhaps for discussion on other mailing lists. Perhaps it should be discussed on other mailing list, but it seems that since SASOS present their designers with far blanker pieces of paper than your average operating system project (mostly because UNIX compatibility is not a straight forward problem) that some thought might be given to it in this context. The fact that SASOSs do not provide any aliasing at their base level must be reflected in the choice of naming schemes since a straight 'name-to-object' mapping is generally insufficient. Two instances spring to mind: dynamic library selection (perhaps you want to run you application with a debugging library without recompiling it) and server access (you want to contact the local instance of a server which exists on all nodes of you machine). Tim ____________________________________________________________ Tim Wilkinson Systems Architecture Research Centre, City University, Northampton Square, London EC1V 0HB, UK. Tel: +44 71 477 8551 Fax: +44 71 477 8587 ____________________________________________________________ From dfk@cs.dartmouth.edu Thu May 5 13:12:01 1994 Received: from hplms26.hpl.hp.com by cs.dartmouth.edu (8.6.5/4.2) id NAA22530; Thu, 5 May 1994 13:11:56 -0400 From: fouts@bozeman.hpl.hp.com Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA25459; Thu, 5 May 1994 10:13:12 -0700 Received: from bozeman.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA05034; Thu, 5 May 1994 10:11:50 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+IOS 3.14) id AA23996; Thu, 5 May 1994 10:14:34 -0700 Date: Thu, 5 May 1994 10:14:34 -0700 Message-Id: <9405051714.AA23996@bozeman.hpl.hp.com> To: shap@viper.cis.upenn.edu Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9405051355.AA23942@hplms26.hpl.hp.com> (shap@viper.cis.upenn.edu) Subject: Re: Namespaces, authority, and location transparency Reply-To: Martin Fouts >>>>> "Jonathan" == Jonathan Shapiro writes: Jonathan> >Marty writes: I'm not sure I understand the simplification. Jonathan> >In Brevix we recognized that protection requires a triple. Jonathan> >There is the object operated on, the operation to be Jonathan> >performed and the agent performing the operation. Jonathan> In an age where to an increasing degree, the agent may be a Jonathan> third-party intermediary that has independent identity from Jonathan> the end client, I wonder how long the notion of "who's Jonathan> asking" will be a sensible question. In short, I think you Jonathan> want a pair: (object, authority), where authority does not Jonathan> imply knowledge of the asker. My triple is (object, action, agent). Your 'authority' replaces my 'agent', but you still need 'action' which is the item you droped from the list, so you still end up with a triple. The reason why I chose 'agent' rather than 'authority' is because agent exists (in the form of thread) as a first class object in Brevix, where as authority is a derived security aspect. It is possible to build a security model above the (object, action, agent) pair which maps authorities to Brevix agents. We encode the idea of authority in our required/possesed rights model. For an agent to be able to perform an action on the object, the object is tagged with a set of "required rights" for each possible action that may be performed on that object and the agent with a set of "possesed rights" If there is a match between the required rights and the possessed rights the action is performed. Determining the match is a property of the security policy which is not implemented by Brevix, so that multiple security policies may exist. Jonathan> > Although I can envision a naming scheme which maps the Jonathan> >apparent names of agents to the address of data structures Jonathan> >representing those agents, I believe that there are simpler Jonathan> >schemes for the os to internally name agents. Similar Jonathan> >comments hold for operations. Jonathan> The protections need to be on something based on the object Jonathan> identity, not the object's human-visible name. There needs Jonathan> to be a layer at which every object is uniquely named. Jonathan> That is the layer where protections should be specified. Jonathan> Anything above that is user-oriented window dressing Jonathan> (important, but not relevant to the discussion of Jonathan> security). I agree. However, in the quoted paragraph I was talking about the OS's view of agent names, not the user's view. Note that in Brevix, agents are simply threads and are named by their system wide unique thread id (which is an ordinal, not a virtual address, because that makes life easier for the thread manager.) Jonathan> [details on protection and privilige elided ...] Jonathan> > Further, if they are likely to change for a long Jonathan> >duration, you may want to migrate only that object from its Jonathan> >current partition to one more appropriate for its new Jonathan> >requirements. The classic example is that of file aging. Jonathan> >Once a file has reached a certain age without being Jonathan> >touched, the odds are very good that it should migrate to a Jonathan> >higher latency lower cost level of the storage hierarchy. Jonathan> If an application has gone to the trouble to explicit Jonathan> request a promotion of service class for an object, the OS Jonathan> should not then demote the object without the application's Jonathan> consent - it violates the contract. That depends on how the contract was written (;-) It is reasonable to have semantics which allow promotion to be automatic with demotion to be usage based. This allows any of a collection of applications to promote, relying on the underlying policy to keep track of demotions, freeing the applications from having to coordinate. There are some aps for which this form of "garbage collection" is reasonable. Jonathan> [other interesting observations elided...] From dfk@cs.dartmouth.edu Thu May 5 14:10:36 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id OAA22935; Thu, 5 May 1994 14:10:35 -0400 Message-Id: <199405051810.OAA22935@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA10845; Thu, 5 May 94 14:08:58 -0400 Date: Thu, 5 May 94 14:08:58 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: sasos@cs.dartmouth.edu In-Reply-To: (message from Tim Wilkinson on Thu, 5 May 1994 17:18:37 +0100 (BST)) Subject: Re: Sharing namespaces Okay, perhaps I'm assuming I want multiple systems to interact but it does seem to be something of a one way decission to me. If they can, you can always not do it, it they can't you can never do it -- if you decide it's not possible, your stuffed if you change your mind. I think that the two issues are orthogonal. If you like, the first question is: "Can I get OS(x) running in a binary-compaitble form on top of my microkernel" the second question is the same one for your OS(y). The third question is can you come up with a mechanism that allows the two to interoperate in some rational fashion. Once you start talking about interoperation, it's a matter of degree. To many end users, the following would be more than adequate: 1. Rationally unify the file systems (relatively simple) 2. Rationally unify the network utilities, most notably email (relatively simple) so I don't have to run more than one. 3. Make all the windows appear on my screen at the same time. 4. Somehow make it so I only need to log in to the machine, not the OS instance. As far as most users are concerned, that would be a single system. The pleasures of the deep semantics are reserved for us OS weenies ;-) As for incompatible semantics - well that's the problem your trying to solve isn't it? I don't think so. I think the goal is not to unify everything, but to make everything interoperate in a well-defined way. This requires unifying certain interfaces (at least to the extent of providing user-invisible translation layers), but hardly all. Unifying the X-Windows and Windows clipboards, for example, and providing an integrated UI look and feel, would cover a lot of ground. Anyhow, ignoring the difficulties of incompatible semantics for the moment and considering different environments views on similar services (networking for example), it seems useful, possibly essential, for sharing to occur. Consider a TCP/IP interface. Multiple environments MUST share the ports correctly otherwise bad things will happen... If I'm trying to build a workstation that provides multi-OS interoperability, you are correct. If I'm trying to build a system that provides hot fail-over support for OLTP, I not only don't want to unify the machine images, I probably want to ensure that they can't get unified by accident. In the latter case I really want to think in terms of running two different machines that are temporarily residing on the same hardware. In this case my two logical machines must maintain distinct IP addresses, in which event the above issue goes away. The point I'm trying to make is that the goal depends on the requirements, and a properly designed microkernel should be flexible enough to support a range of such goals. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Thu May 5 14:13:46 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id OAA22958; Thu, 5 May 1994 14:13:43 -0400 Message-Id: <199405051813.OAA22958@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA10847; Thu, 5 May 94 14:12:34 -0400 Date: Thu, 5 May 94 14:12:34 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: sasos@cs.dartmouth.edu In-Reply-To: (message from Tim Wilkinson on Thu, 5 May 1994 17:29:20 +0100 (BST)) Subject: Re: Extensibility ...UNIX compatibility is not a straight forward problem... The fact that SASOSs do not provide any aliasing at their base level... If the latter is true, then 100% UNIX compatibility is by definition impossible. There are exposed interfaces in the POSIX standards that mandate certain aliasing capabilities, most notably in mmap(2). In the particular case of mmap(2), you can conform to the specification, but this will neither conform to the intent nor to the expectations of applications in the field. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Thu May 5 14:25:48 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id OAA23011; Thu, 5 May 1994 14:25:46 -0400 Message-Id: <199405051825.OAA23011@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA10849; Thu, 5 May 94 14:22:29 -0400 Date: Thu, 5 May 94 14:22:29 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: fouts@hplms2.hpl.hp.com Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9405051714.AA23996@bozeman.hpl.hp.com> (fouts@bozeman.hpl.hp.com) Subject: Re: Namespaces, authority, and location transparency Jonathan> >Marty writes: I'm not sure I understand the simplification. Jonathan> >In Brevix we recognized that protection requires a triple. Jonathan> >There is the object operated on, the operation to be Jonathan> >performed and the agent performing the operation. Jonathan> In an age where to an increasing degree, the agent may be a Jonathan> third-party intermediary that has independent identity from Jonathan> the end client, I wonder how long the notion of "who's Jonathan> asking" will be a sensible question. In short, I think you Jonathan> want a pair: (object, authority), where authority does not Jonathan> imply knowledge of the asker. My triple is (object, action, agent). Your 'authority' replaces my 'agent', but you still need 'action' which is the item you droped from the list, so you still end up with a triple. By authority I meant a capability. A capability conveys the authority to perform an action on an object, and is thus an (action, object) pair. Posession of a capability is a necessary *and sufficient* condition to perform the action on the object, thus, there is no notion of "agent." I believe that I can prove to you that the imposition of an agent on the security model provides no additional security, since you cannot assume that the agent is cooperating - they may be colluding with a third, untrusted party to subvert the security model. In some cases, the collusion is harmful, but imposing the agent can't prevent it. In other cases, the collusion is essential to the application's structure, and imposing the agent precludes it. The failure to acknowledge collusion is the fundamental error in the "don't copy" bit on some capability architectures. Authority propagation can't be controlled that way unless you lock the authority holder in a room with no communication channels. If you manage to do so, you don't really care how many times they copy the authority. In addition, inability to copy the authority defeats the clients right to exercise the authority by way of a third-party, discrete service provider (by discrete I mean a service provider who cannot disclose information to a third party. Under the right conditions this property may be mechanically verifiable). The reason why I chose 'agent' rather than 'authority' is because agent exists (in the form of thread) as a first class object in Brevix, where as authority is a derived security aspect. If your threads are not persistent, then there is a problem with this. If your threads cannot communicate authorities between themselves, then my comment concerning third-party discrete services applies. See the Confused Deputy paper (look in following email for FTP site). Jonathan> If an application has gone to the trouble to explicit Jonathan> request a promotion of service class for an object, the OS Jonathan> should not then demote the object without the application's Jonathan> consent - it violates the contract. That depends on how the contract was written (;-) It is reasonable to have semantics which allow promotion to be automatic with demotion to be usage based... But more problematic to provide NO contract in which both promotion and demotion are explicit. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Thu May 5 14:27:27 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id OAA23030; Thu, 5 May 1994 14:27:22 -0400 Message-Id: <199405051827.OAA23030@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA10901; Thu, 5 May 94 14:27:01 -0400 Date: Thu, 5 May 94 14:27:01 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: sasos@cs.dartmouth.edu In-Reply-To: <9405051714.AA23996@bozeman.hpl.hp.com> (fouts@bozeman.hpl.hp.com) Subject: KeyKOS papers now available for FTP Thanks to the kindness of David Kotz at Dartmouth, most of the KeyKOS papers can now be gotten online by anonymous FTP. They can be found at cs.dartmouth.edu:/pub/sasos/papers/KeyKOS I hope that you find these papers helpful. Concise descriptions follow: The Confused Deputy: Concise description of a difficult security problem that capability-based mechanisms can solve. Originally appeared in OSR in October, 1988. OSRpaper.ps The Key Logic internal version of the KeyKOS architecture paper that appeared in OSR. This is the definitive paper on the KeyKOS architecture, probably the most important paper of the set. It takes several readings to get through it. MicroKernelPaper.ps The USENIX Microkernel I proceedings paper on the KeyKOS architecture, which includes a description of KeyNIX, the UN*X prototype that runs on top of KeyKOS. Those who don't know a lot of the older OS literature and terminology may find this architecture description an easier starting point than the OSR paper, but the OSR paper has seen more polish and is decidedly more accurate on some points. KeyTXF.ps A description of the KeyKOS transaction facility. Some interesting insights into the problem of building a transaction system on top of a persistent computing system. WhyArch.ps A few pages of brief, somewhat rambling scribblings capturing Norm Hardy's shorthand rationales for various decisions. Interesting as much for being a snapshot of the thought process as anything else. From dfk@cs.dartmouth.edu Thu May 5 16:19:39 1994 Received: from hplms26.hpl.hp.com by cs.dartmouth.edu (8.6.5/4.2) id QAA23792; Thu, 5 May 1994 16:19:38 -0400 From: fouts@bozeman.hpl.hp.com Received: from hplms2.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA27569; Thu, 5 May 1994 13:20:04 -0700 Received: from bozeman.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA11735; Thu, 5 May 1994 13:18:41 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+IOS 3.14) id AA24064; Thu, 5 May 1994 13:21:24 -0700 Date: Thu, 5 May 1994 13:21:24 -0700 Message-Id: <9405052021.AA24064@bozeman.hpl.hp.com> To: shap@viper.cis.upenn.edu Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9405051826.AA26382@hplms26.hpl.hp.com> (shap@viper.cis.upenn.edu) Subject: Re: Namespaces, authority, and location transparency Reply-To: Martin Fouts >>>>> "Jonathan" == Jonathan Shapiro writes: Jonathan> [...] Jonathan> By authority I meant a capability. A capability conveys Jonathan> the authority to perform an action on an object, and is Jonathan> thus an (action, object) pair. Posession of a capability Jonathan> is a necessary *and sufficient* condition to perform the Jonathan> action on the object, thus, there is no notion of "agent." "possesion of a capability" implies both a thing possesed (the capability) and a thing possesing. How do you answer the question "Who posseses the capability?" (I mean a very abstract 'who' here.) In Brevix we chose to make the answer explicitly as "the thread". You can claim that you don't care and say "anonymous" in all cases, but you give up accountability. Jonathan> I believe that I can prove to you that the imposition of an Jonathan> agent on the security model provides no additional Jonathan> security, since you cannot assume that the agent is Jonathan> cooperating - they may be colluding with a third, untrusted Jonathan> party to subvert the security model. Security comes in several different flavors, some of which demand accountability. Agents are absolutely necessary in order to answer the accountability questions for those security systems. If all agents are anonymous, then you can't implement logging, for example. Thus, for those systems agent is essential. I think we are in about 95% agreement, but that Brevix doesn't impose any security model, merely provides a set of primitives which allow any model to be implemented through the security policy mechanism. marty From dfk@cs.dartmouth.edu Thu May 5 17:13:46 1994 Received: from viper.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id RAA24088; Thu, 5 May 1994 17:13:30 -0400 Message-Id: <199405052113.RAA24088@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA11217; Thu, 5 May 94 16:56:42 -0400 Date: Thu, 5 May 94 16:56:42 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: fouts@hplms2.hpl.hp.com Cc: gernot@vast.unsw.edu.au, sasos@cs.dartmouth.edu In-Reply-To: <9405052021.AA24064@bozeman.hpl.hp.com> (fouts@bozeman.hpl.hp.com) Subject: Re: Namespaces, authority, and location transparency "possesion of a capability" implies both a thing possesed (the capability) and a thing possesing. How do you answer the question "Who posseses the capability?" (I mean a very abstract 'who' here.) In Brevix we chose to make the answer explicitly as "the thread". You can claim that you don't care and say "anonymous" in all cases, but you give up accountability. You can certainly record what thread of control is responsible for an instance of a capability invocation, but this is useless for purposes of accountability. The overt invoker of the capability may be invoking the authority on behalf of a third party with whom the invoker is colluding. Recording that the invoker invoked the capability gives you no useful insight for purposes of security, unless you are able to prove a priori that such collusion is either impossible or authorized. If you *can* prove this, then simply recording that you gave that party the capability in the first place and that the capability has been invoked at least once is a necessary and sufficient form of accountability. If you are referring to accountability in the sense of NCSC security ratings, note that they agree with this assessment completely. On proper hardware, we believe that KeyKOS currently meets the NCSC A1 rating. [The definition of A1 would of course be revised in practice to avoid actually giving one out - it was intended from the start to be unreachable.] Having said all that, it is possible to require that a call pass some capability identifying the login session (said capability to be provided by the login process and rescinded at logout) as an argument. You must be able to verify that this is in fact a proper login session key, and that the common service does not stockpile such keys (i.e. is discrete). If you can show this, you can then record that login capability in "denatured form" as part of your audit trail. Even so, it is difficult to prevent the sneaky user from getting their hands on that key and handing it to a friend. Jonathan S. Shapiro From dfk@cs.dartmouth.edu Fri May 6 11:19:27 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id LAA28544; Fri, 6 May 1994 11:19:13 -0400 Received: from dedalus.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 6 May 1994 16:23:49 +0100 From: Kevin A Murray Date: Fri, 6 May 1994 16:21:50 +0100 Message-Id: <1846.199405061521@dedalus.cs.city.ac.uk> To: sasos@cs.dartmouth.edu Subject: Re: Namespaces, authority, and location transparency > Jonathan> By authority I meant a capability. A capability conveys > Jonathan> the authority to perform an action on an object, and is > Jonathan> thus an (action, object) pair. Possession of a capability > Jonathan> is a necessary *and sufficient* condition to perform the > Jonathan> action on the object, thus, there is no notion of "agent." [marty:] > "possession of a capability" implies both a thing possessed (the > capability) and a thing possessing. How do you answer the question > "Who possess the capability?" (I mean a very abstract 'who' here.) > In Brevix we chose to make the answer explicitly as "the thread". > You can claim that you don't care and say "anonymous" in all cases, > but you give up accountability. Which, if I've understood what you've said, comes back to the question of naming since you are ``naming'' the utiliser of the capability to support accountability. (I've never liked the idea of possessing a capability, since in my view they are simply a bit string which can freely be copied and distributed.) Thus when an (action, object) tuple is presented to a server for `execution', what matters is 1) can you be sure `who' has presented this tuple and 2) what level of `who' are you interested in. (`who', again, is abstract). The approach used in Angel is to make processes part of the single address space by representing them as an object (which is almost the PCB) which resides there. When the tuple is presented, over an LRPC, a check can be made to ensure which PCB it is coming from (by some fancy footwork this is done with almost no micro-kernel interaction). Given knowledge of the processes controlling object, a server can then extract whatever name it sees fit (including anonymous). Of itself the above mechanism doesn't give you much more in the way of protection, that comes from the way objects are protected in Angel. Angel does not have capabilities, it has biscuits (cookies, if you like --- we're British!). These biscuits do NOT convey authority to perform an operation. What they convey is a set of conditions that must be met before certain operations can be carried out. The conditions are phrased in terms of objects which the caller must already have certain permissions on (or not have). This means that whilst biscuits can be freely distributed amongst potentially dubious processes, there is still an authentication check that takes place. If security can still be breached, then the question arises of who (or what) is at fault. My contention is that the fault would be with the specification of the conditions that need to be met on the biscuit (these are established when a biscuit is created). For example, if the biscuit the allowed `writing' to the `password' object only checked that the caller could read the `passwd' program, rather than was executing it, this is a fault in the specification of the biscuit and not the system itself. [marty:] > I think we are in about 95% agreement, but that Brevix doesn't impose > any security model, merely provides a set of primitives which allow > any model to be implemented through the security policy mechanism. > Ditto for Angel (sort of). [Jonathan:] > Having said all that, it is possible to require that a call pass some > capability identifying the login session (said capability to be > provided by the login process and rescinded at logout) as an argument. > You must be able to verify that this is in fact a proper login session > key, and that the common service does not stockpile such keys (i.e. is > discrete). If you can show this, you can then record that login > capability in "denatured form" as part of your audit trail. I'd agree with that, but the problem would then be that the capability could be copied by some service and mis-used before it could be timed-out or make invalid. This is basically a variant of a trojan horse. How much of this relates to just SASOS', or shows their superiority, and how much is common to all micro-kernel OS's? Kevin From dfk@cs.dartmouth.edu Fri May 13 05:16:53 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id FAA26430; Fri, 13 May 1994 05:16:24 -0400 Received: from bambam.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 13 May 1994 10:19:32 +0100 To: citycs-list-sasos@cs.city.ac.uk Path: tim From: tim@cs.city.ac.uk (Tim Wilkinson) Newsgroups: citycs.list.sasos Subject: Re: Extensibility Date: 13 May 1994 09:11:27 GMT Organization: SARC, City University Lines: 31 Message-Id: <2qvg7v$61j@bambam.cs.city.ac.uk> References: <2qbef6$lf9@bambam.cs.city.ac.uk> Nntp-Posting-Host: wilma.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] Jonathan Shapiro (shap@viper.cis.upenn.edu) wrote: : ...UNIX compatibility is not a straight forward problem... : The fact that SASOSs do not provide any aliasing at their base : level... : If the latter is true, then 100% UNIX compatibility is by definition : impossible. There are exposed interfaces in the POSIX standards that : mandate certain aliasing capabilities, most notably in mmap(2). In : the particular case of mmap(2), you can conform to the specification, : but this will neither conform to the intent nor to the expectations of : applications in the field. While this is undoubtedly true, in Angel 100% UNIX compatibility has never been an explicit aim of the project. There are plenty of arguments to persuade us to develop some form of UNIX environment (which is being done at Imperial College, London by others) but we accept that we can only support a subset (all be it, a large one). However, do you think that this "exposing" of interfaces in POSIX is a good idea or not? Is it only an effort to define a standard which includes what's already there, or is it an attempt to define something which is portable to different basic architectures? I certainly don't think it is the latter. Many element of POSIX implicity expect the underlying system to conform to certain contraints. While I think this is unreasonable, I suspect this is what standards are all about. Tim -- Tim Wilkinson E-mail: tim@cs.city.ac.uk Systems Architecture Research Centre, Fax: +44 71 477 8587 City University, London, UK. Tel: +44 71 477 8551 From dfk@cs.dartmouth.edu Fri May 13 05:58:36 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id FAA26570; Fri, 13 May 1994 05:58:29 -0400 Received: from bambam.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 13 May 1994 11:02:29 +0100 To: citycs-list-sasos@cs.city.ac.uk Path: tim From: tim@cs.city.ac.uk (Tim Wilkinson) Newsgroups: citycs.list.sasos Subject: Re: Sharing namespaces Date: 13 May 1994 09:54:22 GMT Organization: SARC, City University Lines: 83 Message-Id: <2qvioe$61j@bambam.cs.city.ac.uk> References: <2qbe9v$let@bambam.cs.city.ac.uk> Nntp-Posting-Host: wilma.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] Jonathan Shapiro (shap@viper.cis.upenn.edu) wrote: : Once you start talking about interoperation, it's a matter of degree. : To many end users, the following would be more than adequate: : 1. Rationally unify the file systems (relatively simple) : 2. Rationally unify the network utilities, most notably email : (relatively simple) so I don't have to run more than one. : 3. Make all the windows appear on my screen at the same time. : 4. Somehow make it so I only need to log in to the machine, : not the OS instance. : As far as most users are concerned, that would be a single system. : The pleasures of the deep semantics are reserved for us OS weenies ;-) Yes but this is the issue I'm driving (rather badly) towards. Whatever level of interoperability you decide to go for, do you: a) Knock up a solution for the windows, the file systems, the networks, and whatever else you want to unify in an adhoc manner, or b) Actually work out some consistent mechanisms to solve these problems. Now systems like Unix are full of such adhoc mechanism all specifically designed to fix something which does not generalise. A SASOS starts by providing a low level, very general base and little else and should not be allowed to start down this path from which it is very difficult to retrace ones steps. : As for incompatible semantics - well that's the problem your trying : to solve isn't it? : I don't think so. I think the goal is not to unify everything, but to : make everything interoperate in a well-defined way. This requires : unifying certain interfaces (at least to the extent of providing : user-invisible translation layers), but hardly all. Unifying the : X-Windows and Windows clipboards, for example, and providing an : integrated UI look and feel, would cover a lot of ground. Well, it does from the user point of view - does nothing for the applications and services programmers, specially the latter. I been quite suprised with the amount of unification we've achieved in Angel. This has significantly reduced they systems complexity. The need for well defined interfaces may well be paramount, but if you end up with lots of well defined interfaces you might well have not bothered. Can a case be made for a bounded set of interfaces in SASOS systems? : If I'm trying to build a workstation that provides multi-OS : interoperability, you are correct. If I'm trying to build a system : that provides hot fail-over support for OLTP, I not only don't want to : unify the machine images, I probably want to ensure that they can't : get unified by accident. In the latter case I really want to think in : terms of running two different machines that are temporarily residing : on the same hardware. In this case my two logical machines must : maintain distinct IP addresses, in which event the above issue goes : away. Why not? I see this as a problem with your model for supporting hot fail-over for on-line transaction processing rather than a problem with unification. Surely this is problem of fault toleration and isolation rather than a problem caused by allowing flexible interoperation between OS instances. The only benifit in keeping it like this is to simplify the fault problems in this specific instance - it does not help with faults in more general situations. : The point I'm trying to make is that the goal depends on the : requirements, and a properly designed microkernel should be flexible : enough to support a range of such goals. Yes indeed. Tim -- Tim Wilkinson E-mail: tim@cs.city.ac.uk Systems Architecture Research Centre, Fax: +44 71 477 8587 City University, London, UK. Tel: +44 71 477 8551 **** NT - bringing history to life. **** From dfk@cs.dartmouth.edu Fri May 13 06:12:16 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id GAA26613; Fri, 13 May 1994 06:11:43 -0400 Received: from bambam.cs.city.ac.uk by barney.cs.city.ac.uk; Fri, 13 May 1994 11:16:24 +0100 To: citycs-list-sasos@cs.city.ac.uk Path: tim From: tim@cs.city.ac.uk (Tim Wilkinson) Newsgroups: citycs.list.sasos Subject: Re: Namespaces Date: 13 May 1994 10:08:19 GMT Organization: SARC, City University Lines: 21 Message-Id: <2qvjij$61j@bambam.cs.city.ac.uk> Nntp-Posting-Host: wilma.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] : Date: Mon, 2 May 94 16:26:09 +0200 : From: mjs@cs.cornell.edu : A solution that works well is to encode location in the reference, but : to forward if the location changes, and to arrange to update (i.e. : short-cut) references that use the old location. See the following : paper "SSP Chains: Robust, Distributed References Supporting Acyclic : Garbage Collection". Trouble with this, for capabilities at least, is the need to either trace all capabilities in the system so the reference can be updated lazily, or support forwarding of references indefinately. Neither of these solutions is attractive due to problems with scalability, storage and complexity. Tim -- Tim Wilkinson E-mail: tim@cs.city.ac.uk Systems Architecture Research Centre, Fax: +44 71 477 8587 City University, London, UK. Tel: +44 71 477 8551 **** NT - bringing history to life. **** From dfk@cs.dartmouth.edu Fri May 13 09:31:12 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id JAA27825; Fri, 13 May 1994 09:31:09 -0400 Message-Id: <4189.199405131335@barney.cs.city.ac.uk> Received: from COBRA.CIS.UPENN.EDU by barney.cs.city.ac.uk; Fri, 13 May 1994 14:35:47 +0100 Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA02617; Fri, 13 May 94 09:30:10 -0400 Date: Fri, 13 May 94 09:30:10 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: citycs-list-sasos@cs.city.ac.uk In-Reply-To: <2qvg7v$61j@bambam.cs.city.ac.uk> (tim@cs.city.ac.uk) Subject: Re: Extensibility However, do you think that this "exposing" of interfaces in POSIX is a good idea or not? Is it only an effort to define a standard which includes what's already there, or is it an attempt to define something which is portable to different basic architectures? Tim: As I reread, I came to the conclusion that I was agreeing with you, but I still feel this is worth sending out. To the best of my knowledge, the only pragmatically successful standards efforts have consolidated existing work into a common framework, rather than inventing substantially new things or substantial modifications. Committees are not good engines of innovation. At the time that the POSIX effort started, there were no SASOS architectures to consider (or all the ones that existed could support multiple address spaces). We are now in an unfortunate window of time during which this historical artifact will temporarily impede the transfer of technology from research to commercial efforts. Many element of POSIX implicity expect the underlying system to conform to certain contraints. While I think this is unreasonable, Nothing can proceed in a vacuum. Every scientific and social process that I know of proceeds from *some* assumption set. The better ones acknowledge the assumptions they proceed from. Jonathan From dfk@cs.dartmouth.edu Fri May 13 09:41:54 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA27889; Fri, 13 May 1994 09:41:54 -0400 Message-Id: <199405131341.JAA27889@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA02620; Fri, 13 May 94 09:41:18 -0400 Date: Fri, 13 May 94 09:41:18 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: sasos@cs.dartmouth.edu In-Reply-To: <2qvjij$61j@bambam.cs.city.ac.uk> (tim@cs.city.ac.uk) Subject: Re: Namespaces Tim: Are you aware that your replies are directed to citycs-list-sasos@cs.city.ac.uk rather than to the SASOS list? In any case: Trouble with this, for capabilities at least, is the need to either trace all capabilities in the system so the reference can be updated lazily, or support forwarding of references indefinately. Neither of these solutions is attractive due to problems with scalability, storage and complexity. This makes some assumptions that may deserve further exploration. If the capabilities encode the location, then you need some sort of forwarding. If the capabilities are indirect through some system table, then you just need to update the table. You are right about the scalability of forwarding, but it's not all that bad if capabilities are partitioned rather than encrypted. In a partitioned strategy, you don't need to look at all the pages, just the capability pages. Another possibility is to have a lookaside table, on the theory that migration of individual persistent objects is a low-frequency event. I'm inclined to believe that in serious applications, what I want to migrate is clusters of objects, not individual objects. Jonathan By the way, shouldn't that be: **** NT - bringing prehistory to life. **** ^^^ From dfk@cs.dartmouth.edu Fri May 13 09:53:19 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA27976; Fri, 13 May 1994 09:53:18 -0400 Message-Id: <199405131353.JAA27976@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA02625; Fri, 13 May 94 09:52:54 -0400 Date: Fri, 13 May 94 09:52:54 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: sasos@cs.dartmouth.edu In-Reply-To: <2qvioe$61j@bambam.cs.city.ac.uk> (tim@cs.city.ac.uk) Subject: Re: Sharing namespaces Yes but this is the issue I'm driving (rather badly) towards. Whatever level of interoperability you decide to go for, do you: a) Knock up a solution for the windows, the file systems, the networks, and whatever else you want to unify in an adhoc manner, or b) Actually work out some consistent mechanisms to solve these problems. Observation: the idea that windows, file systems, networks, etc. are somehow distinct is itself an artifact of an ad-hoc approach. There exist neither unified name spaces nor unified protection approaches for these resources. Regrettably it is exactly this ad-hoc-ness that you are attempting to emulate. The need for well defined interfaces may well be paramount, but if you end up with lots of well defined interfaces you might well have not bothered. Can a case be made for a bounded set of interfaces in SASOS systems? In the limit, no, for reasons that are fundamental. Any frozen interface encapsulates a set of (hopefully explicit) architectural assumptions. There will always exist those programs whose needs fall outside of those assumptions. There will therefore always exist the need to build special-purpose interfaces. That said, I think a better question (and probably the one you intended) is: is there a minimal set of interfaces that a SASOS system provider should undertake to provide as part of the system. Some thoughts on this: o There needs to be an abstraction layer that provides for application portability. This can be outside the PCB (privileged computing base). This is where most of your question falls. o There needs to be a non-abstracted layer, wherein applications with specific requirements can get very close to the hardware (restriction: not at the cost of loss of security). Sometimes these facilities can be written with a relatively machine-independent interface (consider UNIX /proc, with which I have successfully written multi architecture debuggers). Given the latter, you can afford to choose the former conservatively. : If I'm trying to build a system that provides hot fail-over : support for OLTP, I not only don't want to unify the machine : images, I probably want to ensure that they can't get unified by : accident. Why not? I see this as a problem with your model for supporting hot fail-over for on-line transaction processing rather than a problem with unification. It's a case of optimizing for the common case. You want to build the programs to assume they will run on a single system, and have a (very) fast recovery mechanism. Relocating the programs (rewriting the addresses in the binaries) takes longer than you have. Surely this is problem of fault toleration and isolation rather than a problem caused by allowing flexible interoperation between OS instances. The only benifit in keeping it like this is to simplify the fault problems in this specific instance - it does not help with faults in more general situations. Agreed, but when you are evaluating an architecture, isn't it important to acknowledge and address the real-world boundary cases? Let's try it in a more positive framing: Given two logical machines (i.e. may be multiple workstations linked by a network, but the two are logically independent federations), each running a SASOS, how does one address the need for hot-standby and hot-failover? Jonathan From crow@cs.dartmouth.edu Tue May 24 23:44:41 1994 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id XAA25528; Tue, 24 May 1994 23:44:40 -0400 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.8.1+DND/4.5HUB) id XAA04476; Tue, 24 May 1994 23:44:39 -0400 Message-id: <4369947@dancer.Dartmouth.EDU> Date: 24 May 94 23:44:25 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: SIGMETRICS SASOS paper available To: sasos@cs.dartmouth.edu Our paper, "The Expected Lifetime of ``Single-Address-Space'' Operating Systems" which was presented at the SIGMETRICS '94 conference last week is now available via FTP from cs.dartmouth.edu in the file /pub/sasos/papers/lifetime-sasos.ps The Bibtex entry is in /pub/sasos/sasos.bib. --PC From crow@cs.dartmouth.edu Sun May 29 12:13:47 1994 Received: from bambam.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id MAA03000; Sun, 29 May 1994 12:13:38 -0400 Received: by bambam.cs.city.ac.uk (Smail3.1.28.1 #14) id m0q7nRB-0000xVC; Sun, 29 May 94 17:10 BST To: citycs-list-sasos@cs.city.ac.uk Path: tim From: tim@cs.city.ac.uk (Tim Wilkinson) Newsgroups: citycs.list.sasos Subject: Expected lifetime of ... Date: 29 May 1994 16:10:08 GMT Organization: SARC, City University Lines: 25 Message-ID: <2saep0$qlb@bambam.cs.city.ac.uk> NNTP-Posting-Host: wilma.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] I read the paper "The Expected Lifetime of ``Single-Address-Space'' Operating Systems" by David Kotz and Preston Crow the other day and I have a few thoughts. I think it successfully demonstrates that a "no reuse" policy is doomed to failure but even with a reuse policy in place, it estimates that it will be necessary to adapt to future, larger address spaces, as they become available (eg. 96 and 128bit). If we were to assume for the moment that the world is, in general, happy with multi-address space operating systems, is there really any incentive for processor manufactures to go for still larger address spaces> Now admittedly I remember thinking 32bit was very bit many years ago, but is it different this time? Also, what are the costs in silicon and execution speed in increasing the sizes of the addresses still further (it's bound to slow the ALUs down) unless 128bit integer registers have other useful purposes? Just wondering.... Tim -- Tim Wilkinson E-mail: tim@cs.city.ac.uk Systems Architecture Research Centre, Fax: +44 71 477 8587 City University, London, UK. Tel: +44 71 477 8551 **** NT - bringing history to life. **** From crow@cs.dartmouth.edu Sun May 29 20:22:27 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id UAA04937; Sun, 29 May 1994 20:22:26 -0400 Received: from wildcat.dartmouth.edu by barney.cs.city.ac.uk with smtp (Smail3.1.28.1 #14) id m0q7vCE-0007ETC; Mon, 30 May 94 01:27 BST Received: from localhost by wildcat.dartmouth.edu (8.6.5/4.2) id UAA12932; Sun, 29 May 1994 20:22:16 -0400 Date: Sun, 29 May 1994 20:22:16 -0400 From: dfk@cs.dartmouth.edu (David Kotz) Message-Id: <199405300022.UAA12932@wildcat.dartmouth.edu> To: tim@cs.city.ac.uk CC: citycs-list-sasos@cs.city.ac.uk In-reply-to: <2saep0$qlb@bambam.cs.city.ac.uk> (tim@cs.city.ac.uk) Subject: Re: Expected lifetime of ... Path: tim From: tim@cs.city.ac.uk (Tim Wilkinson) Newsgroups: citycs.list.sasos If we were to assume for the moment that the world is, in general, happy with multi-address space operating systems, is there really any incentive for processor manufactures to go for still larger address spaces? Good question. Another way to look at it: if SASOS really catch on, and become popular (leading to the need for larger address spaces), the manufacturers will then have a motivation to build CPUs with bigger address spaces. If they don't catch, the issue is moot. dave From crow@cs.dartmouth.edu Mon May 30 10:09:42 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id KAA09148; Mon, 30 May 1994 10:09:42 -0400 Message-Id: <199405301409.KAA09148@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA05651; Mon, 30 May 94 10:08:33 -0400 Date: Mon, 30 May 94 10:08:33 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: tim@cs.city.ac.uk Cc: sasos@cs.dartmouth.edu Subject: Re: Expected lifetime of ... If we were to assume for the moment that the world is, in general, happy with multi-address space operating systems, is there really any incentive for processor manufactures to go for still larger address spaces> Now admittedly I remember thinking 32bit was very bit many years ago, but is it different this time? 2^64 is a big number. Suppose you have a processor where each instruction takes 1 nanosecond. Suppose we wish to zero a 2^64 bit address space. This will take (2^64)*(10^-9) seconds. Rounded to the nearest integer, that's: 18,446,744,073 seconds 307,445,734 minutes 5124095 hours 213503 days 585 years For reference, you might bear in mind that a CMOS circuit is a suspension, and is subject to slow dispersion. If nothing else intervenes, a .5 micron circuit has a top life expectancy of 300 years. We might imagine that filling the memory with useful information would take two orders of magnitude longer, but if we take that address space and distribute it using DSM over 1000 processors or so, we're starting to look at something that might get filled with real information within a reasonably small time period. Finally, bear in mind that storage allocation is never done at such a fine granularity; there is inherent waste built in to al of the efficient malloc strategies I know about. So to answer your question: it *is* different, provided that we are talking about 64 bits of address space per process. No single processor is going to fill such an address space in the next 10 years. Multiple processors can. Also, the 2^64 number is deceptive, as you need backing store for it somewhere. The more I read, the more I conclude that 64 bit address spaces are leading people to a "profligate use" approach to memory management. The memory makers will love this, but it won't help us get useful computing done. The computational advantage to 64 bit address spaces lies in simplifying the allocation of memory and supporting algorithms that take advantage of sparsity. Also, what are the costs in silicon and execution speed in increasing the sizes of the addresses still further (it's bound to slow the ALUs down) unless 128bit integer registers have other useful purposes? The problem isn't so much in the addressing as in the ALU. Load offsets tend to be small, because they have to fit in the instruction format. Adding a 13-bit number to a 64 bit number isn't very expensive. You can predict both carries out of bit 13 and you're essentially done. With a proper tree structure you can go a long ways to parallelize this addition. The real problem is instructions that do things like: ld (r1+r2) where you must do the full add. In today's CMOS processes (.5 micron), if you are very careful, you can do about 5 levels of logic on a 4 ns clock. This is enough to add 64 bit numbers. Without having looked at the circuits, I'lg venture to guess that adding 128 bit numbers probably requires another level of logic, which would push you to a 5ns cycle time. Since multiplies and divides are low-frequency operations, it's the additions you're really worried about. Most of the other ALU-type operations are simpler. Jonathan From crow@cs.dartmouth.edu Mon May 30 10:49:31 1994 Received: from wildcat.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id KAA09493; Mon, 30 May 1994 10:49:31 -0400 Received: from localhost by wildcat.dartmouth.edu (8.6.5/4.2) id KAA07241; Mon, 30 May 1994 10:49:27 -0400 Date: Mon, 30 May 1994 10:49:27 -0400 From: dfk@cs.dartmouth.edu (David Kotz) Message-Id: <199405301449.KAA07241@wildcat.dartmouth.edu> To: shap@viper.cis.upenn.edu CC: sasos@cs.dartmouth.edu In-reply-to: <199405301409.KAA09148@cs.dartmouth.edu> (shap@viper.cis.upenn.edu) Subject: Re: Expected lifetime of ... Date: Mon, 30 May 94 10:08:33 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) Cc: sasos@cs.dartmouth.edu Suppose you have a processor where each instruction takes 1 nanosecond. Suppose we wish to zero a 2^64 bit address space. This will take (2^64)*(10^-9) seconds. Rounded to the nearest integer, that's: 18,446,744,073 seconds 307,445,734 minutes 5124095 hours 213503 days 585 years For reference, you might bear in mind that a CMOS circuit is a suspension, and is subject to slow dispersion. If nothing else intervenes, a .5 micron circuit has a top life expectancy of 300 years. You're off a bit here -- you should be able to zero 8 bytes per instruction on a 64-bit machine. However, cache effects will slow this down by adding a few cycles per cache line. So the number is probably closer to 100 years. And don't forget that cycle times will decrease over that 100-year period, shortening it further. Finally, bear in mind that storage allocation is never done at such a fine granularity; there is inherent waste built in to al of the efficient malloc strategies I know about. Sure. This is where you really use the address space: address space that is "consumed" without ever being used (even zeroed). See our paper. dave From crow@cs.dartmouth.edu Mon May 30 19:43:30 1994 Received: from sics.se by cs.dartmouth.edu (8.6.5/4.2) id TAA13608; Mon, 30 May 1994 19:43:27 -0400 From: ans@sics.se Received: from max.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA02231; Tue, 31 May 94 01:43:18 +0200 Received: by max.sics.se (5.65+bind 1.7+ida 1.4.2/SICSclient-1.1) id AA09105 (for ans@sics.se); Tue, 31 May 94 01:43:17 +0200 Date: Tue, 31 May 94 01:43:17 +0200 Message-Id: <9405302343.AA09105@max.sics.se> To: tim@cs.city.ac.uk, shap@viper.cis.upenn.edu Subject: Re: Expected lifetime of ... Cc: sasos@cs.dartmouth.edu > Date: Mon, 30 May 94 10:08:33 -0400 > From: shap@viper.cis.upenn.edu (Jonathan Shapiro) > To: tim@cs.city.ac.uk > Cc: sasos@cs.dartmouth.edu > Subject: Re: Expected lifetime of ... > > If we were to assume for the moment that the world is, in general, happy > with multi-address space operating systems, is there really any incentive > for processor manufactures to go for still larger address spaces> Now > admittedly I remember thinking 32bit was very bit many years ago, but is > it different this time? > > 2^64 is a big number. > > Suppose you have a processor where each instruction takes 1 > nanosecond. Suppose we wish to zero a 2^64 bit address space. This > will take (2^64)*(10^-9) seconds. Rounded to the nearest integer, > that's: > > 18,446,744,073 seconds > 307,445,734 minutes > 5124095 hours > 213503 days > 585 years > .... > We might imagine that filling the memory with useful information would > take two orders of magnitude longer, but if we take that address space > and distribute it using DSM over 1000 processors or so, we're starting > to look at something that might get filled with real information > within a reasonably small time period. Unfortunately as Tim says, most of the world is happy with multi-address space operating systems. Arguably the move from 32 to 64 bits was simply prompted by the fact that 32 bits is no longer enough address space for a single process (application). Moreover it is not unreasonable (and hasn't been for a while now) for customers to have more than 2^32 bytes of on-line storage - a customer can easily argue that they want to mmap their 3Gb database. It will be a while before these customers will be applying the same pressure again to be able to mmap their > 2^64 byte files .. or will it ? Where else can pressure for > 64 bits come from ? The world of functional programmers (et al) is generally happy with 64bits enabling large sparse address spaces with no re-use, fine, but until these applications become a dominant market force they will not be responsible for manufacturers moving to 128bits. I'm not going to hold my breath. It may well be that SASOS's have to "go it alone". It seems the attitude of many micro-processor manufacturers, (at least those from Sun + SGI + Intel that I have spoken to about this), is that SASOS's are a great idea (encouraging) - enabling a number of performance improvement possibilities for their chips - but the bottom line is that until Mickeysoft come out with NT-SASOS or SASOS's take over from SYS-Vr4 big-time they will stick to their current tracks. For example, DEC openly claims its Alpha architecture is "designed for the next 20 years" .. this means no 128bit processor before 2011. A person more cynical than I might suggest that if DEC carry on as they are, they will never have to face this possibility. > Also, what are the costs in silicon and execution > speed in increasing the sizes of the addresses still further (it's bound > to slow the ALUs down) unless 128bit integer registers have other useful > purposes? > > The problem isn't so much in the addressing as in the ALU. Load > offsets tend to be small, because they have to fit in the instruction > format. Adding a 13-bit number to a 64 bit number isn't very > expensive. You can predict both carries out of bit 13 and you're > essentially done. With a proper tree structure you can go a long ways > to parallelize this addition. > > The real problem is instructions that do things like: > > ld (r1+r2) > > where you must do the full add. For both reg+imm and reg+reg address calculations you only have to add sufficient bits to be able to index (and start) the 1st level cache access. For example, on the DEC 21064-* this is an addition of 13 bits, (the cache is 8kb direct mapped), even though the load / store offsets are 16bit. The high order bits of the addition don't have to be ready until one or two load/store unit pipeline stages later - when the cache line tag (and TLB) has to be checked. By allowing only doubleword (4byte) or quadword (8byte) loads and stores Alpha can skip another 2 bits. Neither Alpha, nor MIPS-III allow reg+reg load/store instructions for other performance reasons. (Interestingly MIPS-IV (TFP & T5) have reg+reg ld/st operations). > In today's CMOS processes (.5 micron), if you are very careful, you > can do about 5 levels of logic on a 4 ns clock. This is enough to add > 64 bit numbers. Without having looked at the circuits, I'lg venture > to guess that adding 128 bit numbers probably requires another level > of logic, which would push you to a 5ns cycle time. ".5" micron means a number of different things for different manufacturers. Although the "0.5 micron" refers to the drawn gate length, it is the effective gate length, and gate oxide thickness which more directly affect the transistor speed. It is these latter two which the manufacturers are playing with, so that it is no longer a simple matter to compare two "0.5" micro processes. Other ancillary factors such as the number of metal layers affect gate and overall design density, and hence performance. I should imagine that exactly how many gate levels are possible for each particular process is a closely guarded secret (rather like wafer yeald). As an asside: The "old" alpha chips - 21064-AA @150, 166 & 200 MHz - are produced using a 0.75 micron process. Also, DEC currently produce 275MHz 21064A parts with a "0.5" process, (although not quite shipping yet) - rumour has it they will announce 320MHz parts at the same time. Clearly, they can manage a 64 bit addition in 3.125 micro-seconds. IDT, NEC, and Toshiba are currently delivering MIPS devices with drawn gate lengths of 4 microns, and apparently IDT plans to shrink this process further to 0.35 microns for the 200-MHz R4400 and T5. Of course, the easy alternative to a longer cycle time is to use a shorter cycle time, and execute in two pipeline stages, or two cycles. (+ some vigourous hand waving ;-) > Since multiplies and divides are low-frequency operations, it's the > additions you're really worried about. Most of the other ALU-type > operations are simpler. Hmm, I guess we could count comparison instructions as an obscure form of addition (or subtraction), however reg,reg barrel shifts are also a pain. Moving to a "pure" 128 bit architecture causes a great number of other problems - for example doubling the size of the register file, and more importantly the width of the register busses - then design a 4/6-way superscalar device ..... One other question which might be covered is what use are 128-bit general registers ? ... As an interim, what about playing HP's trick (from their current 32bit PAs) ? ... ie 64 bit registers, and then 64bit segment registers (shudder) appended to make a 128bit address ... (OK, OK, .. no more tomatoes ... ;-) cheers, Ashley. Ashley Saulsbury Swedish Institute of Computer Science (SICS), Box 1263, 16428 Kista, Sweden. Tel: +46 8 752 1570 Fax: +46 8 751 7230 E-mail: ans@sics.se From crow@cs.dartmouth.edu Tue May 31 04:05:14 1994 Received: from didec7.epfl.ch by cs.dartmouth.edu (8.6.5/4.2) id EAA17737; Tue, 31 May 1994 04:05:13 -0400 From: monnier@didec7.epfl.ch Received: by didec7.epfl.ch; id AA03176; Tue, 31 May 1994 10:05:08 +0200 To: sasos@cs.dartmouth.edu Subject: Re: Expected lifetime of ... In-Reply-To: Your message of "Tue, 31 May 94 01:43:17 +0200." <9405302343.AA09105@max.sics.se> Date: Tue, 31 May 94 10:05:07 +0200 Message-Id: <3174.770371507@didec7.epfl.ch> X-Mts: smtp >>>>> "Ashley" == ans writes: Ashley> Unfortunately as Tim says, most of the world is happy with Ashley> multi-address space operating systems. Arguably the move Ashley> from 32 to 64 bits was simply prompted by the fact that 32 Ashley> bits is no longer enough address space for a single Ashley> process (application). Moreover it is not unreasonable Ashley> (and hasn't been for a while now) for customers to have Ashley> more than 2^32 bytes of on-line storage - a customer can Ashley> easily argue that they want to mmap their 3Gb database. Ashley> It will be a while before these customers will be applying Ashley> the same pressure again to be able to mmap their > 2^64 Ashley> byte files .. or will it ? Well, I can't see the problem. The problem of "never reuse address space" seems moot to me: the protection mechanism makes sure you can't access memory you're not supposed to access. So why worry about old pointers or whatever ? So, I can't see the point of not reusing address space, so that 64bits per machine seems largely sufficient for now (and for some more time) Of course, considering big distributed systems, 64bits isn't enough. But then those distributed systems will probably (especially if big) be heterogeneous, which implies some kind of swizzling (unless you force all machines to have similar object sizes (pointer size, data alignment, ..), which seems to be a rather strong requirement). Once you have swizzling, you can have a dist address space of 256bits if you want, even if some machine only has 32bits. How do you plan to avoid swizzling in a serious dist-SASOS ? (even NFS allows heterogeneity) 128bits or more seem to be useful only for some specific ways to implement a SASOS and those ways seem to have further restrictions which make them not so interesting in the real-world. Of course, I'm just a stupid student rambling about stuff I don't know, but could someone explain me why I'm wrong ? Stefan From crow@cs.dartmouth.edu Tue May 31 09:30:29 1994 Received: from bambam.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id JAA19281; Tue, 31 May 1994 09:30:27 -0400 Received: by bambam.cs.city.ac.uk (Smail3.1.28.1 #14) id m0q8TqL-0000xVC; Tue, 31 May 94 14:26 BST To: citycs-list-sasos@cs.city.ac.uk Path: adm2 From: adm2@cs.city.ac.uk (Alan Messer) Newsgroups: citycs.list.sasos Subject: SASOS uses Date: 31 May 1994 13:26:56 GMT Organization: Systems Architecture Research Centre, City University, London, England. Lines: 39 Message-ID: <2sfdv0$6vm@bambam.cs.city.ac.uk> NNTP-Posting-Host: guppy.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] I agree with the 'Expected lifetime' thread that systems with larger than 64-bits will only come about due to the widespread adoption of the SASOS ideas by mainstream companys (such as Mickeysoft :-)). My question is though, why would anyone NEED to use a SASA system? And what would one use one for?? Here at SARC, our main interest for Angel is in the field of Multimedia systems (where large amounts of data must be processed) and perhaps the database area? Whilst these are popular areas, what others could benefit from the simpilifications that SASA systems bring? What areas are other groups aiming their SASOSs at?? And what effect/angle do they bring to the SASOS itself?? And how do they benefit? Without a good reason to change, manufacturers/commerce will not do so. If DBMS systems had not demanded the extra address bits and more so in the future, do you think that DEC would have considered a 64/43-bit Alpha?? No. (Well, Ok, they might have as a marketing ploy - mines got more bits than yours mentality; that is so much in vogue with Console manufacturers!). I realise, of course, that we all are doing this as research and thus needn't have any commercial considerations, but I'm curious anyway. Any thoughts? Alan. -- Alan Messer | E-mail: adm2@cs.city.ac.uk Systems Architecture Research Centre, | cj562@city.ac.uk London, EC1V 0HB | be559@cleveland.freenet.edu Tel: +44 71 477 8551 | (ATK,MIME & PGP2.2 accepted - see plan) Fax: +44 71 477 8587 | From crow@cs.dartmouth.edu Tue May 31 11:37:12 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id LAA21057; Tue, 31 May 1994 11:37:08 -0400 Received: from whistler.cs.washington.edu by barney.cs.city.ac.uk with smtp (Smail3.1.28.1 #14) id m0q8Vwr-0007ETC; Tue, 31 May 94 16:41 BST Received: from localhost (localhost [127.0.0.1]) by whistler.cs.washington.edu (8.6.8/7.2ws+) with SMTP id IAA24681; Tue, 31 May 1994 08:36:29 -0700 Message-Id: <199405311536.IAA24681@whistler.cs.washington.edu> To: adm2@cs.city.ac.uk (Alan Messer) cc: citycs-list-sasos@cs.city.ac.uk Subject: Re: SASOS uses In-reply-to: Your message of "31 May 1994 13:26:56 GMT." <2sfdv0$6vm@bambam.cs.city.ac.uk> Date: Tue, 31 May 1994 08:36:29 PDT From: Hank Levy Well, we have been (Opal) targeted at large integrated design systems, and have been working with Boeing to look at their problems. But the bottom line is that we're YEARs away from knowing whether this approach is the right one, even for limited design environments, so I"m amazed that people are already wondering when vendors are going to change to 96 bits. Seems a little premature. The current generation of processors arrived for a number of reasons. Basically, we ran out of not only virtual address bits, but PHYSICAL address bits, and the latter may be a more pressing problem right now. For there to be a change of technology, there has to be a problem with current systems that the new technology solves, and that solution has to be *much* better than what was done before -- enough better for people to endure the pain of changing. The current 64-bit chips couldn't arrive until chip densities allowed vendors to do it without much performance penalty. E.g., DEC had considered doing 64 bits years ago on the predecessor to Alpha, but decided that both the technology and market weren't ready. In fact, they may be suffering now because Alpha is ahead of the performance needs of the marketplace. Anyway, if you want to know if SASOS is useful, I'd say call back in 10 years. hank From crow@cs.dartmouth.edu Tue May 31 12:14:46 1994 Received: from bambam.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id MAA21450; Tue, 31 May 1994 12:14:45 -0400 Received: by bambam.cs.city.ac.uk (Smail3.1.28.1 #14) id m0q8WPM-0000xVC; Tue, 31 May 94 17:11 BST To: citycs-list-sasos@cs.city.ac.uk Path: adm2 From: adm2@cs.city.ac.uk (Alan Messer) Newsgroups: citycs.list.sasos Subject: Re: SASOS uses Date: 31 May 1994 16:11:15 GMT Organization: Systems Architecture Research Centre, City University, London, England. Lines: 44 Message-ID: <2sfnj3$7i6@bambam.cs.city.ac.uk> References: <2sfmql$7he@bambam.cs.city.ac.uk> NNTP-Posting-Host: guppy.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] Hank Levy (levy@cs.washington.edu) wrote: : Well, we have been (Opal) targeted at large : integrated design systems, and have been : working with Boeing to look at their problems. Fair enough, since I guess they have large databases of parts and designs. : But the bottom line is that we're YEARs away : from knowing whether this approach is the right one, : even for limited design environments, so I"m amazed : that people are already wondering when vendors are : going to change to 96 bits. Seems a little : premature. I think the most important aspect of the "I need more bits" idea is that SASA ideas can be used in large Distributed/Parallel systems or WAN areas, where the number of bits will run out very quickly. But I take the point that these rumblings are in their early stages... : Anyway, if you want to know if SASOS is useful, I'd say : call back in 10 years. I guess I should clarify a little, I didn't mean to ask is a SASOS useful, more what can it be used for/what applications is it likely to benefit. Currently Database and Multimedia seem to be the main areas of benefit. Alan. -- Alan Messer | E-mail: adm2@cs.city.ac.uk Systems Architecture Research Centre, | cj562@city.ac.uk London, EC1V 0HB | be559@cleveland.freenet.edu Tel: +44 71 477 8551 | (ATK,MIME & PGP2.2 accepted - see plan) Fax: +44 71 477 8587 | From crow@cs.dartmouth.edu Tue May 31 16:33:41 1994 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id QAA23971; Tue, 31 May 1994 16:33:40 -0400 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.8.1+DND/4.5HUB) id QAA02940; Tue, 31 May 1994 16:33:38 -0400 Message-id: <4622105@dancer.Dartmouth.EDU> Date: 31 May 94 16:33:27 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: SASOS uses To: sasos@cs.dartmouth.edu Alan Messer (SARC) writes: >My question is >though, why would anyone NEED to use a SASA system? And what would one >use one for?? (SASA? Single-Address-Space Architecture?) A SASOS has, as has been mentioned, great potential for database and multimedia systems. It also has potential for distributed computing. About a year ago I spoke with people in charge of computer systems at Morrison Knudsen (a Fortune 500 construction firm), and their greatest concern was the inability to share information on current systems. A SASOS system could provide a single system image to address this problem. A SASOS can prove itself worthy for specific applications on a single system, but distribution is critical for general purpose use. --PC From crow@cs.dartmouth.edu Tue May 31 16:49:24 1994 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id QAA24237; Tue, 31 May 1994 16:49:23 -0400 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.8.1+DND/4.5HUB) id QAA05294; Tue, 31 May 1994 16:49:21 -0400 Message-id: <4622967@dancer.Dartmouth.EDU> Date: 31 May 94 16:49:10 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: Expected lifetime of ... To: sasos@cs.dartmouth.edu Stefan writes: (Re: Expected lifetime of ... ) >Of course, considering big distributed systems, 64bits isn't >enough. But then those distributed systems will probably (especially >if big) be heterogeneous, which implies some kind of swizzling (unless >you force all machines to have similar object sizes (pointer size, >data alignment, ..), which seems to be a rather strong requirement). >Once you have swizzling, you can have a dist address space of 256bits >if you want, even if some machine only has 32bits. >How do you plan to avoid swizzling in a serious dist-SASOS ? (even NFS >allows heterogeneity) I don't see where having a heterogeneous distributed address space necessarily implies pointer swizzling. Certainly, some sort of adjustment is necessary if the real address registers are too small for the address space, but other than that, there doesn't need to be a problem. The real problem arrises when you try to pass data between heterogeneous machines--adjusting endian-ness and other data formats. But this is just a part of a larger problem: What sorts of tools are needed for working in a SASOS environment? In Unix, we have numerous ASCII-based tools. In a SASOS, we presumably wouldn't convert everything to text, implying that we need a new set of general tools. (Do we want self-describing data structures? Do we need a strictly object-oriented system with a standard set of methods for all data?) Clearly, we can't share code between architectures...or can we? If we keep the source with the binary, then the code could be automatically re-compiled. Or if we try to run a binary for another architecture, it could automatically shift the thread to a machine that is capable of running it. --PC From crow@cs.dartmouth.edu Tue May 31 17:04:45 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id RAA24587; Tue, 31 May 1994 17:04:44 -0400 Message-Id: <199405312104.RAA24587@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA09501; Tue, 31 May 94 17:04:26 -0400 Date: Tue, 31 May 94 17:04:26 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: preston.crow@dancer.dartmouth.edu Cc: sasos@cs.dartmouth.edu In-Reply-To: <4622105@dancer.Dartmouth.EDU> (Preston.F.Crow@dartmouth.edu) Subject: Re: SASOS uses About a year ago I spoke with people in charge of computer systems at Morrison Knudsen (a Fortune 500 construction firm), and their greatest concern was the inability to share information on current systems. A SASOS system could provide a single system image to address this problem. Danger, Will Robinson! In a sense, EROS is a SASOS. It doesn't provide a single address space at the addressing level, but it does at the storage level. While the two are not nearly the same, they raise some similar issues when we speak of single system images. Last year, I spent about 4 months thinking about how to distribute EROS. The idea was to take a LAN (or in our case, a set of ATM links) and in essence provide multiple processors on the single level store. The current EROS system keeps some maps of in-core pages that would need to be extended, but this didn't seem unduly hard. A multiprocessor design had been considered for its predecessor, KeyKOS. The difficulty is that a failure in the network takes down everything in the cluster. To implement persistence, EROS needs to be able to checkpoint, and failure to reach a node is fatal. People *say* they want a single system image, but they don't seem to understand the reliability implications of the underlying networks. Jonathan From crow@cs.dartmouth.edu Tue May 31 17:19:37 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id RAA24774; Tue, 31 May 1994 17:19:36 -0400 Message-Id: <199405312119.RAA24774@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA09737; Tue, 31 May 94 17:19:20 -0400 Date: Tue, 31 May 94 17:19:20 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: preston.crow@dancer.dartmouth.edu Cc: sasos@cs.dartmouth.edu In-Reply-To: <4622967@dancer.Dartmouth.EDU> (Preston.F.Crow@dartmouth.edu) Subject: Re: Expected lifetime of ... >How do you plan to avoid swizzling in a serious dist-SASOS ? (even NFS >allows heterogeneity) I don't see where having a heterogeneous distributed address space necessarily implies pointer swizzling. Certainly, some sort of adjustment is necessary if the real address registers are too small for the address space, but other than that, there doesn't need to be a problem. There are a couple of gotchas. They've been explored pretty thoroughly in the OODB world. 1) Not all pointers the same size. This one is so obvious that people tend to think it through. 2) Alignments often differ. This one has pretty horrendous consequences. 3) Endianness. This isn't nearly as bad as people think. The correction can be done in place on all real architectures. 4) Differences in floating point formats. Don't forget the VAX floats, though if you are willing to write off the VAX line and declare victory with IEEE this is probably not as big an issue. Also, you can define the translations as not necessarily being information preserving, though this can be a source of subtle bugs. If you're willing to change the source language, you can use the approach that Oberon takes. There's an excellent treatment of the structure layout and garbage collector mechanism in the book Project Oberon. Basically, every object carries with it a layout descriptor pointer that is filled in at instantiation time and identifies the pointers. This could be straightforwardly extended to handle alignment, or you could define the alignment support requirements in the language itself. Note also that alignment is a performance issue, not a correctness issue. You *can* work around foreign alignments if you're prepared to do enough work in the compiler. Jonathan From crow@cs.dartmouth.edu Wed Jun 1 04:58:42 1994 Received: from bambam.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id EAA28956; Wed, 1 Jun 1994 04:58:40 -0400 Received: by bambam.cs.city.ac.uk (Smail3.1.28.1 #14) id m0q8m4f-0000xVC; Wed, 1 Jun 94 09:54 BST To: citycs-list-sasos@cs.city.ac.uk Path: adm2 From: adm2@cs.city.ac.uk (Alan Messer) Newsgroups: citycs.list.sasos Subject: SASOS tools (Was: Expected lifetime of ...) Date: 1 Jun 1994 08:54:56 GMT Organization: Systems Architecture Research Centre, City University, London, England. Lines: 39 Message-ID: <2shid0$bcf@bambam.cs.city.ac.uk> References: <2sg96e$8d6@bambam.cs.city.ac.uk> NNTP-Posting-Host: guppy.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] Preston F. Crow (Preston.F.Crow@dartmouth.edu) wrote: : What sorts of tools are needed for working in a SASOS environment? In : Unix, we have numerous ASCII-based tools. In a SASOS, we presumably : wouldn't convert everything to text, implying that we need a new set : of general tools. (Do we want self-describing data structures? Do we : need a strictly object-oriented system with a standard set of methods : for all data?) An interesting point and one which recently I have been considering w.r.t. homogeneous systems. I consider that we need a OO system where objects communicate by sharing data structures (clients are then informed of alterations to these shared structures). The naming between these objects is globally indirect (such that an object doesn't know which object it is communicating to or where it is receiving data from) and this way objects can act as components (i.e. are interchangeable). The form of the objects and the data transferred is where it gets really interesting and depends on your purpose, but currently I'm looking at the GUI/Windowing area where I believe a language along the same lines as Postscript, but in the form of a tree data structure (in the form of an abstract syntax tree - AST), can generate the entire windowing system (sub-system) and functionalty from these component (system or user defined) objects. What other types of objects/tools would we need in a more general purpose system along the same lines, where data can be usefully shared?? Alan. -- Alan Messer | E-mail: adm2@cs.city.ac.uk Systems Architecture Research Centre, | cj562@city.ac.uk London, EC1V 0HB | be559@cleveland.freenet.edu Tel: +44 71 477 8551 | (ATK,MIME & PGP2.2 accepted - see plan) Fax: +44 71 477 8587 | From crow@cs.dartmouth.edu Wed Jun 1 05:06:21 1994 Received: from bambam.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id FAA28993; Wed, 1 Jun 1994 05:06:20 -0400 Received: by bambam.cs.city.ac.uk (Smail3.1.28.1 #14) id m0q8mCJ-0000xVC; Wed, 1 Jun 94 10:02 BST To: citycs-list-sasos@cs.city.ac.uk Path: adm2 From: adm2@cs.city.ac.uk (Alan Messer) Newsgroups: citycs.list.sasos Subject: Re: SASOS uses Date: 1 Jun 1994 09:02:50 GMT Organization: Systems Architecture Research Centre, City University, London, England. Lines: 32 Message-ID: <2shirq$bcf@bambam.cs.city.ac.uk> References: <2sg84t$8b8@bambam.cs.city.ac.uk> NNTP-Posting-Host: guppy.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] Preston F. Crow (Preston.F.Crow@dartmouth.edu) wrote: : Alan Messer (SARC) writes: : >My question is : >though, why would anyone NEED to use a SASA system? And what would one : >use one for?? : (SASA? Single-Address-Space Architecture?) Yep. Isn't this a widely used acronym?? : A SASOS can prove itself worthy for specific applications on a single : system, but distribution is critical for general purpose use. Agreed. Particularly, if it can be extended/of benefit to reasonable sized networks (a large company) or even MAN/WAN situations. (As with the "Expected lifetime thread"). Alan. -- Alan Messer | E-mail: adm2@cs.city.ac.uk Systems Architecture Research Centre, | cj562@city.ac.uk London, EC1V 0HB | be559@cleveland.freenet.edu Tel: +44 71 477 8551 | (ATK,MIME & PGP2.2 accepted - see plan) Fax: +44 71 477 8587 | From crow@cs.dartmouth.edu Wed Jun 1 07:35:33 1994 Received: from thialfi.cs.cornell.edu by cs.dartmouth.edu (8.6.5/4.2) id HAA29482; Wed, 1 Jun 1994 07:35:32 -0400 Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99E) id AA21171; Wed, 1 Jun 94 07:35:27 -0400 Received: from ROCKY.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D) id AA19724; Wed, 1 Jun 94 07:35:28 -0400 From: mjs@cs.cornell.edu (Marc Shapiro) Date: Wed, 1 Jun 94 07:35:25 -0400 Message-Id: <9406011135.AA10325@rocky.cs.cornell.edu> Received: by rocky.cs.cornell.edu (5.67/N-0.13) id AA10325; Wed, 1 Jun 94 07:35:25 -0400 To: shap@viper.cis.upenn.edu Cc: preston.crow@dancer.dartmouth.edu, sasos@cs.dartmouth.edu In-Reply-To: <199405312104.RAA24587@cs.dartmouth.edu> (shap@viper.cis.upenn.edu) Subject: SASOS, reliability, transactions, single system image || Date: Tue, 31 May 94 17:04:26 -0400 || From: shap@viper.cis.upenn.edu (Jonathan Shapiro) || || The difficulty is that a failure in the network takes down everything || in the cluster. To implement persistence, EROS needs to be able to || checkpoint, and failure to reach a node is fatal. I'd like to take up a related topic. It should be possible to control when your updates are made visible. It's called transactions of course. They are not only useful for reliability, they are also essential for the application semantics. There is a nice property of distributed systems that helps implementing transactions: you implement abort/commit by just retaining your updates in the local cache; if you commit, then flush the cache all at once; if you abort, just throw away the data. Let's not throw away the nice properties of distributed systems just for the sake of the conceptual elegance of single-system-image. There are also implications with respect to the consistency protocol; since most transaction mechanisms come with locking, protocols like entry consistency come naturally. || People *say* they want a single system image, but they don't seem to || understand the reliability implications of the underlying networks. What applications need are the *abstraction* of a single system image. The system can implement this abstraction in different ways. A "pure" SASOS would implement this abstraction by physically replicating data pages identically everywhere. This is simple but has all the drawbacks we have been discussing recently (e.g. can't move data around, reliability problems, etc.). But there are other ways that don't have the drawbacks. In my current system I give each process the illusion of a single image, but internally I swizzle pointers and I move things around. This gives my system a lot more freedom. -- Marc Shapiro M. Shapiro, INRIA, on sabbatical at Cornell University, 4106 Upson Hall, Ithaca NY 14583, USA; e-mail: mjs@cs.cornell.edu tel.: +1(607)255-5418; fax: +1(607)255-4428 From crow@cs.dartmouth.edu Wed Jun 1 10:01:49 1994 Received: from thialfi.cs.cornell.edu by cs.dartmouth.edu (8.6.5/4.2) id KAA00754; Wed, 1 Jun 1994 10:01:49 -0400 Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99E) id AA22376; Wed, 1 Jun 94 10:01:44 -0400 Received: from GRIMNIR.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D) id AA25953; Wed, 1 Jun 94 10:01:47 -0400 From: mjs@cs.cornell.edu (Marc Shapiro) Date: Wed, 1 Jun 94 10:01:42 -0400 Message-Id: <9406011401.AA02613@grimnir.cs.cornell.edu> Received: by grimnir.cs.cornell.edu (5.67/N-0.13) id AA02613; Wed, 1 Jun 94 10:01:42 -0400 To: sasos@cs.dartmouth.edu Subject: single system image More on the abstraction of a single shared system image. In the past, this has been done at least three different levels: language (Emerald, Orca), RPC (Corba, SSP Chains), and pointers (Opal). The latter is more "pure" and easier to support with primitive C/C++ compilers. But it gives up a level of indirection that is extremely valuable in the other solutions. It is that level of indirection that supports migration, replication, and fragmentation of objects, not to mention compacting garbage collection and automatic persistence by reachability. In my current work at Cornell, called RDOSS, ordinary C or C++ programs can use pointers directly (including legal pointer arithmetic). Internally, the system transforms the data into a location-independent reference scheme. Based on this internal representation, I can do compacting garbage collection and persistence by reachability. The key is that that while a datum is actively in use at a process, it is guaranteed that its address will not change. Thus, I retain the level of indirection as long as a datum is in system space, but I give it up when the datum goes into application space. So, for instance, even if a datum shows up at the same address in all applications, it need not be mapped at the same address in the system space. This allows me to play all sorts of useful tricks. From crow@cs.dartmouth.edu Wed Jun 1 10:02:13 1994 Received: from thialfi.cs.cornell.edu by cs.dartmouth.edu (8.6.5/4.2) id KAA00760; Wed, 1 Jun 1994 10:02:12 -0400 Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99E) id AA22386; Wed, 1 Jun 94 10:02:09 -0400 Received: from GRIMNIR.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D) id AA25982; Wed, 1 Jun 94 10:02:11 -0400 From: mjs@cs.cornell.edu (Marc Shapiro) Date: Wed, 1 Jun 94 10:02:07 -0400 Message-Id: <9406011402.AA02616@grimnir.cs.cornell.edu> Received: by grimnir.cs.cornell.edu (5.67/N-0.13) id AA02616; Wed, 1 Jun 94 10:02:07 -0400 To: sasos@cs.dartmouth.edu Subject: single system image More on the abstraction of a single shared system image. In the past, this has been done at least three different levels: language (Emerald, Orca), RPC (Corba, SSP Chains), and pointers (Opal). The latter is more "pure" and easier to support with primitive C/C++ compilers. But it gives up a level of indirection that is extremely valuable in the other solutions. It is that level of indirection that supports migration, replication, and fragmentation of objects, not to mention compacting garbage collection and automatic persistence by reachability. In my current work at Cornell, called RDOSS, ordinary C or C++ programs can use pointers directly (including legal pointer arithmetic). Internally, the system transforms the data into a location-independent reference scheme. Based on this internal representation, I can do compacting garbage collection and persistence by reachability. The key is that that while a datum is actively in use at a process, it is guaranteed that its address will not change. Thus, I retain the level of indirection as long as a datum is in system space, but I give it up when the datum goes into application space. So, for instance, even if a datum shows up at the same address in all applications, it need not be mapped at the same address in the system space. This allows me to play all sorts of useful tricks. -- Marc Shapiro M. Shapiro, INRIA, on sabbatical at Cornell University, 4106 Upson Hall, Ithaca NY 14583, USA; e-mail: mjs@cs.cornell.edu tel.: +1(607)255-5418; fax: +1(607)255-4428 From crow@cs.dartmouth.edu Wed Jun 1 14:11:41 1994 Received: from june.cs.washington.edu by cs.dartmouth.edu (8.6.5/4.2) id OAA02914; Wed, 1 Jun 1994 14:11:39 -0400 Received: from localhost (localhost [127.0.0.1]) by june.cs.washington.edu (8.6.8/7.2ju) with SMTP id LAA14872; Wed, 1 Jun 1994 11:11:20 -0700 Message-Id: <199406011811.LAA14872@june.cs.washington.edu> To: mjs@cs.cornell.edu (Marc Shapiro) cc: shap@viper.cis.upenn.edu, preston.crow@dancer.dartmouth.edu, sasos@cs.dartmouth.edu, chase@cs.washington.edu Subject: Re: SASOS, reliability, transactions, single system image In-reply-to: Your message of "Wed, 01 Jun 1994 07:35:25 EDT." <9406011135.AA10325@rocky.cs.cornell.edu> Date: Wed, 01 Jun 1994 11:11:19 PDT From: Jeff Chase > [Marc Shapiro writes:] > What applications need are the *abstraction* of a single system image. > The system can implement this abstraction in different ways. A "pure" > SASOS would implement this abstraction by physically replicating data > pages identically everywhere. ... > More on the abstraction of a single shared system image. In the past, > this has been done at least three different levels: language (Emerald, > Orca), RPC (Corba, SSP Chains), and pointers (Opal). The latter is > more "pure" and easier to support with primitive C/C++ compilers. But > it gives up a level of indirection that is extremely valuable in the > other solutions. ... > In my current system I give each process > the illusion of a single image, but internally I swizzle pointers and > I move things around. This gives my system a lot more freedom. ... > The key is that that while a datum is actively in use at a process, it > is guaranteed that its address will not change. Thus, I retain the > level of indirection as long as a datum is in system space, but I give > it up when the datum goes into application space. So, for instance, > even if a datum shows up at the same address in all applications, it > need not be mapped at the same address in the system space. Marc, do I understand you to be saying that a single address space somehow forces you into particular approaches for coherency and object storage management? I'll enthusiastically agree that replicating pages everywhere is dumb, and that indirection has its uses in some language environments. But I don't believe that an SAS precludes using any intelligent approach to coherency/recoverability/storage management, including those involving pointer indirection. It seems that what you really mean is that swizzling is an *alternative* to an SAS, and that, given swizzling, an SAS is not helpful. Here is my response: (1) Even if you swizzle, using an SAS for active data ("application space") frees you from having to copy objects between the address spaces of applications that are cooperating through the persistent store. Your last sentence quoted above seems to agree. So a single-node transient SAS is a good idea even if you swizzle. (2) Swizzling incoming/outgoing data is memory-intensive, like copying. Like copying, the cost of swizzling doesn't matter much given today's slow I/O systems. It may never matter for some applications. But like copying, it is worthwhile to explore ways to get rid of swizzling, i.e., use a persistent and distributed SAS. (3) I'm not yet convinced that swizzling ever buys you anything, unless you are short of address space or you have heterogeneity to deal with. Your distinction between "application space" and "system space" seems artificial to me...and it smells like you're asking me to copy data between them. - Jeff From crow@cs.dartmouth.edu Mon Jun 6 11:29:27 1994 Received: from thialfi.cs.cornell.edu by cs.dartmouth.edu (8.6.5/4.2) id LAA09476; Mon, 6 Jun 1994 11:29:26 -0400 Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99E) id AA16039; Mon, 6 Jun 94 11:27:59 -0400 Received: from GRIMNIR.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D) id AA27523; Mon, 6 Jun 94 11:28:02 -0400 From: mjs@cs.cornell.edu (Marc Shapiro) Date: Mon, 6 Jun 94 11:27:56 -0400 Message-Id: <9406061527.AA06533@grimnir.cs.cornell.edu> Received: by grimnir.cs.cornell.edu (5.67/N-0.13) id AA06533; Mon, 6 Jun 94 11:27:56 -0400 To: chase@cs.washington.edu Cc: sasos@cs.dartmouth.edu In-Reply-To: <199406011811.LAA14872@june.cs.washington.edu> (message from Jeff Chase on Wed, 01 Jun 1994 11:11:19 PDT) Subject: Re: SASOS, reliability, transactions, single system image || Date: Wed, 01 Jun 1994 11:11:19 PDT || From: Jeff Chase || || I don't believe that an SAS precludes using any intelligent approach || to coherency/recoverability/storage management, including those involving || pointer indirection. Well if you use any form of indirection, *everybody* who can use that reference needs to adhere to the indirection policy. You are not being particularly helpful by pushing the responsibility up to the application or the language environment. || (1) Even if you swizzle, using an SAS for active data ("application || space") frees you from having to copy objects between the address spaces || of applications that are cooperating through the persistent store. Sure. It makes sense to share memory and to avoid swizzling as much as possible. However it would be a mistake to forbid more flexible address management whenever needed. For instance COOL has a notion of "cluster space"; processes that belong to a cluster space can share a set of clusters without swizzling. However there is no obligation that all processes are in the same cluster space. This seems like a sensible thing to do. The implication is that the SAS mechanism should not be pushed too deep into the OS (or, god forbid, in the hardware) where it cannot be switched off. || Your distinction between "application space" and || "system space" seems artificial to me...and it smells like you're || asking me to copy data between them. I have a very simple problem. At transaction commit, my transaction manager needs to access both the before-image and the after-image of a segment. If all images of the segment *must* reside at the same virtual address, I am screwed. Conversely, when replicating or caching a segment, you have to be very careful what you tell users. If you tell them that at the same address they will find "the same" segment, you are giving up the flexibility of exporting different images of the segment. So, no fragmented objects, and no weak consistency protocols. (Of course you can still do it, but users will find out that you are lying to them and be very confused.) You are correct that the weakness of this approach is that I probably will end up doing a lot of unnecessary copying. I'm betting that a good implementation of copy-on-write will be able to hide that cost. (Currently I'm on top of SunOS, where COW is just wishful thinking.) Marc From crow@cs.dartmouth.edu Mon Jun 6 15:06:40 1994 Received: from june.cs.washington.edu by cs.dartmouth.edu (8.6.5/4.2) id PAA11433; Mon, 6 Jun 1994 15:06:39 -0400 Received: from localhost (localhost [127.0.0.1]) by june.cs.washington.edu (8.6.8/7.2ju) with SMTP id MAA13850; Mon, 6 Jun 1994 12:05:10 -0700 Message-Id: <199406061905.MAA13850@june.cs.washington.edu> To: mjs@cs.cornell.edu (Marc Shapiro) cc: chase@cs.washington.edu, sasos@cs.dartmouth.edu, chase@cs.washington.edu Subject: Re: SASOS, reliability, transactions, single system image In-reply-to: Your message of "Mon, 06 Jun 1994 11:27:56 EDT." <9406061527.AA06533@grimnir.cs.cornell.edu> Date: Mon, 06 Jun 1994 12:05:09 PDT From: Jeff Chase > From: mjs@cs.cornell.edu (Marc Shapiro) > Date: Mon, 6 Jun 94 11:27:56 -0400 > Message-Id: <9406061527.AA06533@grimnir.cs.cornell.edu> > Received: by grimnir.cs.cornell.edu (5.67/N-0.13) > id AA06533; Mon, 6 Jun 94 11:27:56 -0400 > To: chase@cs.washington.edu > Cc: sasos@cs.dartmouth.edu > Subject: Re: SASOS, reliability, transactions, single system image > > || Date: Wed, 01 Jun 1994 11:11:19 PDT > || From: Jeff Chase > || > || I don't believe that an SAS precludes using any intelligent approach > || to coherency/recoverability/storage management, including those involving > || pointer indirection. > > Well if you use any form of indirection, *everybody* who can use that > reference needs to adhere to the indirection policy. You are not > being particularly helpful by pushing the responsibility up to the > application or the language environment. Huh? I thought *you* were the one proposing to push it up to the language environment! I was just saying I wouldn't stop you. > For instance COOL has a notion of "cluster space"; processes that > belong to a cluster space can share a set of clusters without > swizzling. However there is no obligation that all processes are in > the same cluster space. This seems like a sensible thing to do. > > The implication is that the SAS mechanism should not be pushed too > deep into the OS (or, god forbid, in the hardware) where it cannot be > switched off. > Maybe. But there are some benefits to pushing it down low. So clearly we need to understand the costs better -- why you would ever want to switch it off. Flexibility always "sounds sensible", but to quote David Cheriton, you don't need flexibility to steer both front wheels of your car independently. > || Your distinction between "application space" and > || "system space" seems artificial to me...and it smells like you're > || asking me to copy data between them. > > I have a very simple problem. At transaction commit, my transaction > manager needs to access both the before-image and the after-image of a > segment. If all images of the segment *must* reside at the same > virtual address, I am screwed. These are copies, right? You copied the before images onto a log maybe? Presumably you're not using COW for that (;-)). I can't imagine how I could ever build you a system that forces you to place your copies at the same address. The main restriction of an SAS is that the copies can *never* reside at the same address. Your point is completely lost on me. > Conversely, when replicating or caching a segment, you have to be very > careful what you tell users. If you tell them that at the same > address they will find "the same" segment, you are giving up the > flexibility of exporting different images of the segment. So, no > fragmented objects, and no weak consistency protocols. (Of course you > can still do it, but users will find out that you are lying to them > and be very confused.) > Surely you do not believe that by claiming a single address space I have committed myself to sequential consistency? I believe you are confusing "shared address space" with "shared memory", and I think the DASH people might disagree with you. To put it another way, if the users ever find out you were lying, then either they or you have a bug (e.g., failure to acquire a lock in a weakly coherent system). Jeff From crow@cs.dartmouth.edu Tue Jun 7 10:55:04 1994 Received: from thialfi.cs.cornell.edu by cs.dartmouth.edu (8.6.5/4.2) id KAA18895; Tue, 7 Jun 1994 10:55:03 -0400 Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99E) id AA27606; Tue, 7 Jun 94 10:53:34 -0400 Received: from GRIMNIR.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D) id AA29680; Tue, 7 Jun 94 10:53:38 -0400 From: mjs@cs.cornell.edu (Marc Shapiro) Date: Tue, 7 Jun 94 10:53:33 -0400 Message-Id: <9406071453.AA07042@grimnir.cs.cornell.edu> Received: by grimnir.cs.cornell.edu (5.67/N-0.13) id AA07042; Tue, 7 Jun 94 10:53:33 -0400 To: chase@cs.washington.edu Cc: chase@cs.washington.edu, sasos@cs.dartmouth.edu, chase@cs.washington.edu In-Reply-To: <199406061905.MAA13850@june.cs.washington.edu> (message from Jeff Chase on Mon, 06 Jun 1994 12:05:09 PDT) Subject: Re: SASOS, reliability, transactions, single system image Let me re-state my transaction manager problem a bit more clearly. Consider some segment S. Its address in the SAS is, say 0x10000. The sequence of events is the following: - the transaction manager maps the value of S before starting a transaction (the before-value), S0, at 0x10000 - the manager exports this value to a transaction; the transaction maps S0, at 0x10000, and writes onto it (in-place), yielding value S1. - the transaction commits, and the manager now maps both values of S, i.e. S0 (before-value) and S1 (after-value). S1 has to be mapped at some other address, say 0x20000 - if the commit fails, the manager throws S1 away. If it succeeds, it throws S0 away. Now the correct value of S is at location 0x20000. (It can't throw away either version until the outcome of the commit is known.) - When the next transaction comes along, at what address does it map S? My understanding of how a SASOS works is that it must be mapped at 0x20000; but that's wrong, because all the pointers into S are based on address 0x10000. It seems obvious that the solution is to have applications all map whatever version of S they are working on at 0x10000, but let the transaction manager map its versions wherever. Doesn't a similar situation arise when dealing with weak consistency protocols? There probably are times where different processes on the same machine are working with different versions of the same data. Marc From crow@cs.dartmouth.edu Tue Jun 7 12:33:23 1994 Received: from ucrengr.ucr.edu by cs.dartmouth.edu (8.6.5/4.2) id MAA20134; Tue, 7 Jun 1994 12:33:22 -0400 Received: from ironman.ucr.edu (ironman.ucr.edu [138.23.166.88]) by ucrengr.ucr.edu (8.6.8/8.6.6) with ESMTP id JAA04563; Tue, 7 Jun 1994 09:31:00 -0700 From: brett fleisch Received: (brett@localhost) by ironman.ucr.edu (8.6.8/8.6.6) id JAA22986; Tue, 7 Jun 1994 09:31:51 -0700 Message-Id: <199406071631.JAA22986@ironman.ucr.edu> Subject: Re: SASOS, reliability, transactions, single system image To: mjs@cs.cornell.edu (Marc Shapiro) Date: Tue, 7 Jun 1994 09:31:50 +0000 (BST) Cc: chase@cs.washington.edu, sasos@cs.dartmouth.edu In-Reply-To: <9406071453.AA07042@grimnir.cs.cornell.edu> from "Marc Shapiro" at Jun 7, 94 10:53:33 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2928 > > Let me re-state my transaction manager problem a bit more clearly. > Consider some segment S. Its address in the SAS is, say 0x10000. The > sequence of events is the following: > > - the transaction manager maps the value of S before starting a > transaction (the before-value), S0, at 0x10000 > > - the manager exports this value to a transaction; the transaction > maps S0, at 0x10000, and writes onto it (in-place), yielding value S1. > > - the transaction commits, and the manager now maps both values of S, > i.e. S0 (before-value) and S1 (after-value). S1 has to be mapped > at some other address, say 0x20000 > > - if the commit fails, the manager throws S1 away. If it succeeds, > it throws S0 away. Now the correct value of S is at location > 0x20000. (It can't throw away either version until the outcome of > the commit is known.) > > - When the next transaction comes along, at what address does it map > S? My understanding of how a SASOS works is that it must be mapped > at 0x20000; but that's wrong, because all the pointers into S are > based on address 0x10000. > > It seems obvious that the solution is to have applications all map > whatever version of S they are working on at 0x10000, but let the > transaction manager map its versions wherever. > We deal with a similar problem in Mirage and Mirage+ DSM that uses the segment model (specifically that provided by System V IPC). All of the pointers in the segment must be self-relative so that processes that share the segment remotely and choose to map the segment to different address ranges can deal with the pointers properly. In practice, most users of the segment choose to map the segments to the same address range at each site so the problems you mentioned are avoided. In the case where it may not be possible to avoid the problems you described, self-relative pointers are needed. For example, it is possible in Mirage+ to map a segment twice (or more) in the address range of a ONE process. In this case internal addresses must be self-relative or there will be chaos. Fabry's paper presents some potential solutions that perhaps we could review for use in this context. > Doesn't a similar situation arise when dealing with weak consistency > protocols? There probably are times where different processes on the > same machine are working with different versions of the same data. > > Marc Interesting idea. You are suggesting that "like" segments mapped to different address ranges may need different consistency protocols. That seems logically equivalent to "typing" groups of processes that share the segments to have "consistency views". /brett -- Brett D. Fleisch Assistant Professor Department of Computer Science University of California Riverside, CA 92521 - 0304 Phone:(909)787-7206 FAX:(909)787-4643 brett@cs.ucr.edu From crow@cs.dartmouth.edu Tue Jun 7 17:22:25 1994 Received: from sics.se by cs.dartmouth.edu (8.6.5/4.2) id RAA02722; Tue, 7 Jun 1994 17:22:22 -0400 From: ans@sics.se Received: from max.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA12188; Tue, 7 Jun 94 23:20:51 +0200 Received: by max.sics.se (5.65+bind 1.7+ida 1.4.2/SICSclient-1.1) id AA26248 (for ans@sics.se); Tue, 7 Jun 94 23:20:50 +0200 Date: Tue, 7 Jun 94 23:20:50 +0200 Message-Id: <9406072120.AA26248@max.sics.se> To: mjs@cs.cornell.edu Subject: Re: SASOS, reliability, transactions, single system image Cc: chase@cs.washington.edu, sasos@cs.dartmouth.edu > From: mjs@cs.cornell.edu (Marc Shapiro) > Date: Tue, 7 Jun 94 10:53:33 -0400 > To: chase@cs.washington.edu > Cc: chase@cs.washington.edu, sasos@cs.dartmouth.edu, chase@cs.washington.edu > Subject: Re: SASOS, reliability, transactions, single system image > > Let me re-state my transaction manager problem a bit more clearly. > Consider some segment S. Its address in the SAS is, say 0x10000. The > sequence of events is the following: > > - the transaction manager maps the value of S before starting a > transaction (the before-value), S0, at 0x10000 > > - the manager exports this value to a transaction; the transaction > maps S0, at 0x10000, and writes onto it (in-place), yielding value S1. > > - the transaction commits, and the manager now maps both values of S, > i.e. S0 (before-value) and S1 (after-value). S1 has to be mapped > at some other address, say 0x20000 > > - if the commit fails, the manager throws S1 away. If it succeeds, > it throws S0 away. Now the correct value of S is at location > 0x20000. (It can't throw away either version until the outcome of > the commit is known.) > > - When the next transaction comes along, at what address does it map > S? My understanding of how a SASOS works is that it must be mapped > at 0x20000; but that's wrong, because all the pointers into S are > based on address 0x10000. > > It seems obvious that the solution is to have applications all map > whatever version of S they are working on at 0x10000, but let the > transaction manager map its versions wherever. Yes .. why not ? A problem arises if you want to export both S1 and S0 to another machine (processor) simultaneously - then (as you say) you have a naming problem since in a/an SAS you would want to use the address to name data. The server or manager can do what ever it likes with different copies of the data internally (as long as it takes care of how they are exported) - it is, after all, only the support mechanism for the paradigm you want. What hurts you is, if a manager needs to "use" the data in S0 and S1 *simultaneously*. For example, follow pointers in both as part of some operation (in your example: the "commit" phase). As you say, in both S0 and S1 pointers to data within the same region (S) were created in each when they were placed at address 0x10000. So, although pointers pointing outside region S will be OK, those self (region) referential pointers will be wrong in S1 when it is mapped to 0x20000 - they now point to S0. A base+offset pointer scheme (only storing the offsets in S) works until you mix them with pointers to data outside S - once you adjust the base, all the offsets are wrong for these external references. You could use swizzling - if you can statically determine where pointers are stored - but then you have to do this on the way in and then back again if your commit completes and you have to remap S1 back to 0x10000 for the clients. Your other option is to check each pointer you get from S1 (check for the range 0x10000->0x10000+len) and adjust it before use - this hurts you for each pointer access, but maybe not much; for processors like the Alpha you can do this in about 5 additional instructions (7 cycles). But, you have these same or worse problems in multi-address space OSs too. > Doesn't a similar situation arise when dealing with weak consistency > protocols? There probably are times where different processes on the > same machine are working with different versions of the same data. There are similarities, except that weak/release consistency memory models explicity allow for different processors to see different values at the same instant. Indeed, they encourage it ! The key point is that the consistency of data is an orthogonal issue to the address space policy. The beauty of single address space is that it can be used as a unique naming scheme for some data - there is however, no reason why that data should be correct (ie the same) accross all machines. What is important is that the data named (by a particular address) is *consistent* with respect to a particular view point at a particular instant. A trivial example: Address A points to a number representing the "number of wives" (sorry, "significant others") person A has. (Some might argue for a boolean, but we must remember the population of Utah ;-) Depending on the consistency model, different machines may find different numbers at location A. What is important is that different machines do not find the string "Car" ! - since the address A is a unique data identifier which implicitly types the data to be found - even if it is not identical on all machines. This is what seperates consistency from chaos. There are then added complications with address space re-use. *SEE Asside* All the weaker consistency models provide a mechanism to guarantee the *correctness* of the data at address A - usually the acquire/release mechanism. A simple implementation of a weaker memory model does not have to hold onto previous data values. The complications and similarity you describe arise when you mix a memory consistency model implementation with fault tolerance - then you have to stash data for roll-back. But, if stashing is all you do, then you can store the back-up copies at any address in the server/manager. cheers, Ashley. Asside: The words "Single Address Space" could imply a sequentially consistent view of the address space (ie the use of addresses *not* the *data* held at those addresses). However, it seems to me that address space usage (ie virtual address allocation) has potential for being weakly consistent. This would make life easier and faster for address space allocation locally - without having to pre-partition or pre-allocate address space tokens to different machines in a distributed system. Consider: An address space manager can perform an acquire on a range of virtual addresses. The manager can then allocate and deallocate regions from this as it likes. If such an allocated region is to be exported to say other machines, then the manager must perform a release on the acquired address range after allocating the region. This ensures that other address space managers (after performing their respective acquires) will see the allocated region *on their next acquire*. The advantage being that, for regions which are not going to be exported out of a process(or) (or machine maybe) - for example a stack region - the region can simply be allocated and deallocated as needed within the acquired section of the address space - there is no need to inform or invalidate other address space managers until a release (or their acquire) is performed much later. For a region of permenant data, or data to be exported & shared an acquire/release is required to create the space, and again to relinquish it. We still have a single address space system, it is just weakly consistent. Note: This is *not* the same as a multi-address space system as a region mapped at address X on one machine must still be mapped at address X on another machine if it is t be shared. Food for thought ? Comments ? P.S. > From: mjs@cs.cornell.edu (Marc Shapiro) > Date: Mon, 6 Jun 94 11:27:56 -0400 > Subject: Re: SASOS, reliability, transactions, single system image > (Currently I'm on top of SunOS, where COW is just wishful thinking.) Have you tried: mmap or mprotect with PROT_READ to copy read-only the pages you want to COW, then catch the SIGSEGV when the page is written ? Your handler can be defined : void handler(int sig, int code, struct sigcontext * scp, caddr_t addr) code == SEGV_PROT for the write protected page. then just bcopy the data to a clean page, and re-mmap that page PROT_READ|PROT_WRITE in at PAGE(addr) (you may want to fix the protection original too). Its a cheap way to build a user-level DVSM system. Of course it takes a while to get into the signal handler - but this may be better than taking up to 128 first level data cache misses for each page unnecessarily copied ... especially since you can mprotect multiple pages. If your'e running Solaris .. deep joy .. your'e in for a bundle of fun doing the same thing ... Ashley Saulsbury Swedish Institute of Computer Science (SICS), Box 1263, 16428 Kista, Sweden. Tel: +46 8 752 1570 Fax: +46 8 751 7230 E-mail: ans@sics.se From crow@cs.dartmouth.edu Mon Jun 13 15:11:24 1994 Received: from bambam.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id PAA09040; Mon, 13 Jun 1994 15:11:18 -0400 Received: by bambam.cs.city.ac.uk (Smail3.1.28.1 #14) id m0qDHKo-0000xMC; Mon, 13 Jun 94 20:06 BST To: citycs-list-sasos@cs.city.ac.uk Path: tim From: tim@cs.city.ac.uk (Tim Wilkinson) Newsgroups: citycs.list.sasos Subject: Re: SASOS, reliability, transactions, single system image Date: 13 Jun 1994 19:06:12 GMT Organization: SARC, City University Lines: 59 Message-ID: <2tian4$mpv@bambam.cs.city.ac.uk> References: <2t2pvr$mhu@bambam.cs.city.ac.uk> NNTP-Posting-Host: wilma.cs.city.ac.uk X-Newsreader: TIN [version 1.2 PL2] ans@sics.se wrote: : > [Commit example deleted] : > : > It seems obvious that the solution is to have applications all map : > whatever version of S they are working on at 0x10000, but let the : > transaction manager map its versions wherever. : Yes .. why not ? A problem arises if you want to export both S1 : and S0 to another machine (processor) simultaneously - then (as you : say) you have a naming problem since in a/an SAS you would want to use : the address to name data. : The server or manager can do what ever it likes with : different copies of the data internally (as long as it takes care of : how they are exported) - it is, after all, only the support mechanism : for the paradigm you want. Seems to me that the possible of having essentially different data at two different addresses might be okay for different machines but reintroduces problematic virtual address aliases that have been removed by the adoption of a SAS if adopted on one machine. Allowing any Sn to be mapped at 0x10000 simply throws away the single address space and we're back into multi-address space systems (however you choose to look at it). If multiple applications wish to see multiple version of data at the same address the only option is to do some ``fancy footwork'' with indirection or swizziling as has been suggested. Of course, it this transaction system mearly wishes to hold an old copy in case the transaction fails to commit, it could always use a COW scheme to hold the copy at another address and similarly to replace it in case of failure. : > Doesn't a similar situation arise when dealing with weak consistency : > protocols? There probably are times where different processes on the : > same machine are working with different versions of the same data. : There are similarities, except that weak/release consistency memory models : explicity allow for different processors to see different values at the : same instant. Indeed, they encourage it ! Now of course it is entirely different from any kind of weak coherency protocol since they deal with different machines where you have distinct copies of data already. Such systems cannot expect application to rely on these copies being distinct otherwise they'll fail when their not. : The key point is that the consistency of data is an orthogonal : issue to the address space policy. The key point is that consistency of data should not be confused with different data. The first allows for optimisation to be made, the other needs to be guaranteed. Tim (better late then never - well probably). -- Tim Wilkinson E-mail: tim@cs.city.ac.uk Systems Architecture Research Centre, Fax: +44 71 477 8587 City University, London, UK. Tel: +44 71 477 8551 **** NT - bringing history to life. **** From crow@cs.dartmouth.edu Thu Jun 30 02:52:02 1994 Received: from asuvax.eas.asu.edu by cs.dartmouth.edu (8.6.5/4.2) id CAA21650; Thu, 30 Jun 1994 02:52:01 -0400 Received: from enws237.eas.asu.edu by asuvax.eas.asu.edu with SMTP id AA10347 (5.65c/IDA-1.4.4 for sasos@cs.dartmouth.edu); Wed, 29 Jun 1994 23:52:56 -0700 Received: by enws237.eas.asu.edu (4.1/SMI-4.1) id AA21313; Wed, 29 Jun 94 23:00:55 MST Date: Wed, 29 Jun 94 23:00:55 MST From: ikim@enws237.eas.asu.edu (Ilmin Kim) Message-Id: <9406300600.AA21313@enws237.eas.asu.edu> To: sasos@cs.dartmouth.edu I need some advices. Pls help me! Recently, I summited my dissertation proposal about SASOS. The proposal includes memory mapping & remote page handling schemes. Main references are Mungi, Monads and Kai Li's DSM papers. I was told I have to consider hardware constraints to implement my memory system. I told my design is for memory managing policy and policy is orthogonal to implementation mechanism. Also many papers did not mention about underlying Hardware. Now, I have to define hardware interface for my design and consider underlying hardware in detail. I have no idea right now. Would you give me some advise or some information or references? For example, how can I implemented inverted page table? Any difference from traditional OS? Kim. From crow@cs.dartmouth.edu Thu Jun 30 13:23:59 1994 Received: from asuvax.eas.asu.edu by cs.dartmouth.edu (8.6.5/4.2) id NAA25517; Thu, 30 Jun 1994 13:23:58 -0400 Received: from enws237.eas.asu.edu by asuvax.eas.asu.edu with SMTP id AA03602 (5.65c/IDA-1.4.4 for sasos@cs.dartmouth.edu); Thu, 30 Jun 1994 10:24:51 -0700 Received: by enws237.eas.asu.edu (4.1/SMI-4.1) id AA21749; Thu, 30 Jun 94 10:17:37 MST Date: Thu, 30 Jun 94 10:17:37 MST From: ikim@enws237.eas.asu.edu (Ilmin Kim) Message-Id: <9406301717.AA21749@enws237.eas.asu.edu> To: sasos@cs.dartmouth.edu Thanks for many responses!!! I think I should have expained my proposal (about memory mapping) briefly. (don't expect too much. I am far from bright) My design is based on Mungi. Virtual space is partitioned. Each partition has same size. Maintain a global data structure Partition_Table (node_id,partition_id). Each node become a manager node for its mounted partitions. (manager node keep track of the current owner: as Li's paper) My design uses inverted page table instead of multi-level page table(Mungi). I belive the virtual space will be more and more fragemented as time passes, which makes multi-level PT has to keep un-necessary virtual pages. My page table does not keep remote, unallcated and unknown pages. Therefore, hint field is not maintained. The mapping function f has two forms f(virtual page) -> local physical page: done by local page table f(virtual page) -> remote physical page: done by remote page handler When a remote page fault occurs, find a manger node by look-up partition_table. The manager node will keep track of the current owner and keeps information about the owner and copy-set.(details are omitted) I still think I don't have to consider underlying hardware. Any kinds of advise for the hardware assumption are welcomed. Thanks in advance. --- I.Kim. From crow@cs.dartmouth.edu Thu Jun 30 14:10:36 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id OAA26012; Thu, 30 Jun 1994 14:10:35 -0400 Message-Id: <199406301810.OAA26012@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA27429; Thu, 30 Jun 94 14:09:30 -0400 Date: Thu, 30 Jun 94 14:09:30 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: ikim@enws237.eas.asu.edu Cc: sasos@cs.dartmouth.edu In-Reply-To: <9406301717.AA21749@enws237.eas.asu.edu> (ikim@enws237.eas.asu.edu) My design uses inverted page table instead of multi-level page table(Mungi). I belive the virtual space will be more and more fragemented as time passes, which makes multi-level PT has to keep un-necessary virtual pages. I still think I don't have to consider underlying hardware. Any kinds of advise for the hardware assumption are welcomed. This sequence of statements is contradictory. Suggestion: make no statement about the required hardware handling of page tables; you aren't in a position to control it in any case. Stick to dealing with how your software will handle logical mappings. I'm not familiar with Mungi, so I cannot really comment on the rest. A strategic choice of partitioning will allow you to make use of the hardware to do much of the remote mapping management cheaply. Finally, a proposed memory mapping scheme that does not present at least one implementation in detail is essentially useless. Jonathan S. Shapiro From crow@cs.dartmouth.edu Thu Jun 30 18:08:04 1994 Received: from staff.cs.su.OZ.AU by cs.dartmouth.edu (8.6.5/4.2) id SAA29885; Thu, 30 Jun 1994 18:08:00 -0400 From: johnr@gh.cs.su.oz.au Received: from gh.cs.su.oz.au by staff.cs.su.OZ.AU (mail from johnr for sasos@cs.dartmouth.edu) with MHSnet (insertion MHSnet site: staff.cs.su.oz.au); Fri, 01 Jul 1994 08:06:31 +1000 Received: from milawa.gh.cs.su.OZ.AU. (insecurely) by staff.cs.su.OZ.AU. (Mail from johnr@gh.cs.su.oz.au to sasos@cs.dartmouth.edu); Fri, 01 Jul 1994 02:21:11 +1000 Received: by milawa.gh.cs.su.oz.au; id AA05686; Fri, 1 Jul 1994 08:06:27 +1000 Message-Id: <9406302206.AA05686@milawa.gh.cs.su.oz.au> To: sasos@cs.dartmouth.edu Date: Fri, 01 Jul 94 08:06:27 +1000 X-Mts: smtp Fcc: mailout In-reply-to: Your message of Wed, 29 Jun 94 23:00:55 MST. <9406300600.AA21313@enws237.eas.asu.edu> -------- > I need some advices. Pls help me! > > Recently, I summited my dissertation proposal about SASOS. > The proposal includes memory mapping & remote page handling schemes. > Main references are Mungi, Monads and Kai Li's DSM papers. > > I was told I have to consider hardware constraints to implement my memory > system. I told my design is for memory managing policy and policy is orthogon > al > to implementation mechanism. Also many papers did not mention about underlyin > g > Hardware. > > Now, I have to define hardware interface for my design and consider underlyin > g > hardware in detail. > I have no idea right now. > > Would you give me some advise or some information or references? > > For example, how can I implemented inverted page table? Any difference from > traditional OS? > > Kim. > I suggest you look at our paper on management of large virtual memories in the (British) Computer Journal - [1] Rosenberg, J., Keedy, J. L. and Abramson, D. "Addressing Large Virtual Memories", The Computer Journal, vol 35, 4, pp. 369-376, 1992. There are severeal other references in that paper. John ------- John Rosenberg phone: +61 2 692 4840 Basser Department of Computer Science fax: +61 2 692 3838 University of Sydney Mobile: +61 18 253001 New South Wales 2006 Australia From crow@cs.dartmouth.edu Fri Jul 1 09:05:21 1994 Received: from asuvax.eas.asu.edu by cs.dartmouth.edu (8.6.5/4.2) id JAA02714; Fri, 1 Jul 1994 09:05:20 -0400 Received: from enws237.eas.asu.edu by asuvax.eas.asu.edu with SMTP id AA17554 (5.65c/IDA-1.4.4 for sasos@cs.dartmouth.edu); Fri, 1 Jul 1994 06:07:39 -0700 Received: by enws237.eas.asu.edu (4.1/SMI-4.1) id AA22972; Fri, 1 Jul 94 06:00:25 MST Date: Fri, 1 Jul 94 06:00:25 MST From: ikim@enws237.eas.asu.edu (Ilmin Kim) Message-Id: <9407011300.AA22972@enws237.eas.asu.edu> To: sasos@cs.dartmouth.edu Thanks very much for advises! Now, I found every recommended paper and reading papers. >A strategic choice of partitioning will allow you to make use of the >hardware to do much of the remote mapping management cheaply. > I have no idea. Could give me some examples? >Finally, a proposed memory mapping scheme that does not present at >least one implementation in detail is essentially useless. > > >Jonathan S. Shapiro > One more question about 'inverted page table' It is from "addressing mechanisms for large virtual memories" computer journal vol 35, no 4, 1992. P372 "the page table width increases only logarithmically with the size of the virtual memory. Therefore increasing from a conventional virtual address size of 32 ibts to a very large virtual memory with 128-bit addresses does not significantly increases the cost" How does it increase only logarithmically? --Kim From crow@cs.dartmouth.edu Fri Jul 1 11:14:49 1994 Received: from cobra.cis.upenn.edu by cs.dartmouth.edu (8.6.5/4.2) id LAA03544; Fri, 1 Jul 1994 11:14:48 -0400 Message-Id: <199407011514.LAA03544@cs.dartmouth.edu> Received: by cobra.cis.upenn.edu (1.37.109.4/16.2) id AA28774; Fri, 1 Jul 94 11:13:41 -0400 Date: Fri, 1 Jul 94 11:13:41 -0400 From: shap@viper.cis.upenn.edu (Jonathan Shapiro) To: ikim@enws237.eas.asu.edu Cc: sasos@cs.dartmouth.edu In-Reply-To: <9407011300.AA22972@enws237.eas.asu.edu> (ikim@enws237.eas.asu.edu) Subject: Inverted Page Table Size This is somewhat introductory. I debated removing the CC but decided to let it be. You may want to skip this if you already grok inverted page tables. >A strategic choice of partitioning will allow you to make use of the >hardware to do much of the remote mapping management cheaply. > I have no idea. Could give me some examples? Suppose you have a 32 bit address space with 4K pages and a tree-structured two-level page table. Then each level in the tree translates 10 bits of virtual address. If your partition size is selected to be 2^22 bytes, then you end up mapping partitions in a single level of mapping table. The numbers change, but a similar thing can be done in a 64 bit address space. One more question about 'inverted page table' It is from "addressing mechanisms for large virtual memories" computer journal vol 35, no 4, 1992. P372 "the page table width increases only logarithmically with the size of the virtual memory.... How does it increase only logarithmically? What you have quoted is wrong for a typical inverted page table design, though it may be true of the particular one they were describing. The memory space required by a hash table based addressing scheme depends on three factors: 1. The size of the hash table 2. The size of the hash list entries. 3. The number of pages that are actually mapped, as opposed to the number of virtual pages that exist. The number of entries in the hash table is determined by the hash function used. It's typically a power of two. The size of the hash list entries scales *linearly* with the size of the address; if you double the number of bits in the address you double the size of the hash list entries. But the number of hash list entries is equal to: min(hash table size, number of mapped pages). Typically when you go to a larger address space you also go to a larger page size. For example, it is quite common for 64 bit machines to implement 8K or 16K pages, while most 32 bit machines implement 4K pages. If you double the address bits, you double the size of the hash entries. If you double the page size, you (approximately) halve the number of pages you need to map for a given program, thus halving the number of hash entries you need. On balance, the total space used to map a mid-sized process with a hash table stays about the same from one address space size to the next. Try to track down one of the Power2 or RS6000 books that describe their memory mapping in detail. Looking at a real implementation may help. Jonathan S. Shapiro Synergistic Computing Associates From crow@cs.dartmouth.edu Tue Jul 12 12:28:06 1994 Received: from barney.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id MAA13768; Tue, 12 Jul 1994 12:27:59 -0400 Received: from imag.imag.fr by barney.cs.city.ac.uk with smtp (Smail3.1.28.1 #14) id m0qNkfB-0007EvC; Tue, 12 Jul 94 17:26 BST Received: from borabora.imag.fr by imag.imag.fr with SMTP id AA00712 (5.65c8/IDA-1.4.4 for ); Tue, 12 Jul 1994 18:17:08 +0200 Received: by borabora.imag.fr (4.1/5.17) id AA28746; Tue, 12 Jul 94 18:18:57 +0200 Date: Tue, 12 Jul 94 18:18:57 +0200 From: Sacha.Krakowiak@imag.fr (Sacha Krakowiak) Message-Id: <9407121618.AA28746@borabora.imag.fr> To: Paulo.Ferreira@inria.fr, ans@sics.se, citycs-list-sasos@cs.city.ac.uk, colin@cs.st-andrew.ac.uk, em@info.ucl.ac.be, eychenne@aar.alcatel-alsthom.fr, fowler@diku.dk, geoff@camp.lancs.ac.uk, haertig@gmd.de, herman@cs.kuleuven.ac.be, jk@doc.ic.ac.uk, jnm@doc.ic.ac.uk, jpiquer@dcc.uchile.cl, kaiser@gmd.de, koch@dku.dk, kroeger@gmdzi.gmd.de, mehaut@lifl.fr, schwaab@loria.loria.fr, schwarz@informatik.uni-kl.de, wsinpim@win.tue.nl, yolande@cs.kuleuwen.ac.be Subject: European Seminar on Distributed Systems (ERSADS) Call for papers and participation European Research Seminar on Advances in Distributed Systems (ERSADS) L'Alpe d'Huez (Is\`{e}re, France) - April 3-7, 1995 Organized by: Institut d'Etudes Sup\'{e}rieures Avanc\'{e}es de Grenoble Institut IMAG - INRIA (Unit\'{e} de Recherche Rh\^{o}ne-Alpes) with the support of Rank Xerox Research Centre and ESPRIT Basic Research Action BROADCAST The Seminar is both an Advanced School and a research Workshop, bringing together doctoral students and junior academic or industrial researchers active in the area of Distributed Computing Systems. It is intended to favour cross-fertilization of ideas and to address fundamental and practical aspects. It combines in-depth surveys on research topics of both practical and theoretical interest in Distributed Systems, by recognized experts, and presentations of ongoing work by the participants. The schedule leaves time for informal exchanges and outdoors activities. The Seminar will take place at l'Alpe d'Huez, a skiing resort located in the French Alps, about 60 km south-east of Grenoble. Attendance is limited to 50. To apply, send an application form, with or without a workshop submission, by November 15, 1994. Submission to the workshop is not required for attendance, but priority is given to submitters. Submissions (4-6 pages, in English) are invited in the following areas: distributed algorithms; distributed systems architecture; distributed operating systems and databases; languages, tools and services for distributed applications; case studies of distributed systems and applications. Programme Surveys: Howard Green (GEC Plessey Telecom) Requirements for Distributed Systems (1) Daniel McCue (Xerox) Requirements for Distributed Systems (2) \"{O}zalp Babao\u{g}lu (Universit\`{a} di Bologna) Understanding Distributed Algorithms Ralf Guido Herrtwich (IBM European Network Centre) System Support for Multimedia Hermann Kopetz (Technische Universit\"{a}t Wien) Real-Time Distributed Systems Patrick Valduriez (INRIA) Distributed Database Systems Workshop: Presentations of work in progress. About 20 presentations (30 minutes) selected by the Scientific Committee, from the submitted contributions. Information and registration: ERSADS, c/o Bull-IMAG, 2 av. de Vignate, 38610 Gi\`{e}res, France. e-mail: ersads@imag.fr Scientific Committee: Sacha Krakowiak (Universit\'{e} Joseph Fourier, Grenoble), Derek McAuley (Cambridge University), Sape Mullender (Universiteit Twente), J\"{u}rgen Nehmer (Universit\"{a}t Kaiserslautern), Marc Shapiro (INRIA), Santosh Shrivastava (University of Newcastle upon Tyne), Sam Toueg (Cornell University). Directors of the Seminar: S. Krakowiak, M. Shapiro Application form is attached. Application forms are also available by ftp on ftp.imag.fr:/pub/ersads or by WWW on URL ftp://ftp.imag.fr/pub/ersads ------------------------------------------------------------------------------- European Research Seminar on Advances in Distributed Systems (ERSADS) April 3-7, 1995 Organized by IMAG and INRIA. Sponsored by Rank Xerox ---------------------------------------------------------------------- APPLICATION FORM (please print) ---------------------------------------------------------------------- Family name .......................................... First name ........................................... Address of institution Name ............................................ Street ............................................ City ............................................ Country............................................ Phone: ................ Fax : ................ e-mail:................ Are you submitting a paper for presentation? _ Yes |_| papers (4 to 6 pages, in English) are due by November 15, 1994 _ No |_| Status: (tick one) _ |_| Doctoral Student - proof of status required _ |_| Researcher/Faculty - proof of status required _ |_| Industry Required accomodation (tick one) _ |_| Double room - I wish to share a room with ........ _ |_| Single room The cost of the Seminar is: For students: double room 4300 FF (3625.63 FF + 18.6% VAT) single room 5300 FF (4468.80 FF + 18.6% VAT) For University faculty/researchers double room 5500 FF (4637.44 FF + 18.6% VAT) single room 6400 FF (5396.29 FF + 18.6% VAT) For participants from industry double room 7400 FF (6239.46 FF + 18.6% VAT) single room 8500 FF (7166.95 FF + 18.6% VAT) This cost covers tuition and proceedings, full board and lodging from dinner on Sunday 2 April to breakfast on Saturday 8 April 1994, coffee breaks, and transportation from and to Grenoble, on April 2 and April 8, respectively. The cost does NOT include transportation from the participant's home place to and from Grenoble. Deadlines --------- For applications without paper submission : Feb. 28, 1995 For applications with paper submission Paper due (8 copies) : November 15, 1994 Decision about paper acceptance: Jan 15, 1995 (*) Camera-ready paper due March 1, 1995 (*) Decision about paper acceptance has no impact on attendance, i.e. you may attend the Seminar even if your submission is not accepted. Attendance is limited, and we only have a limited number of single rooms. Please return the application form as soon as possible. Applications and papers are to be sent to: ERSADS 95 c/o Bull-IMAG, 2, avenue de Vignate 38610 Gieres, France Fax: +33 76 54 76 15 Payment ------- Registration will only be effective after payment of the registration fee. The fee must be paid in French currency, by check to the name of Agent comptable du CNRS (ERSADS 95) to be sent at the above address, or by money order to the name of: CNRS Agent comptable secondaire Rue des Martyrs, BP 166X 38042 Grenoble Cedex, France Tresorerie Principale de Grenoble code banque (bank code): 10071 code guichet (branch code): 38000 no de compte (account nr): 00003000056-07 (please specify "ERSADS 95") From crow@cs.dartmouth.edu Tue Jul 12 16:47:20 1994 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id QAA15586; Tue, 12 Jul 1994 16:47:20 -0400 Received: from dancer.Dartmouth.EDU by dartvax.dartmouth.edu (8.6.8.1+DND/4.5HUB) id QAA22871; Tue, 12 Jul 1994 16:46:11 -0400 Message-id: <5422017@dancer.Dartmouth.EDU> Date: 12 Jul 94 16:46:05 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: SASOS WWW archive To: sasos@cs.dartmouth.edu I've put together a WWW archive of SASOS-related material. To access it, use a browser such as Mosaic or Lynx and goto the URL: http://www.cs.dartmouth.edu/cs_archive/sasos/sasos.html Probably the most exciting information currently available is the bibliography, which we've converted to HTML. Many of the papers have links from the bibliography to the full text. I would be happy to receive comments and suggestions. Also, if you know of a paper that should be listed, or if the full text is available on the net, please let me know, and I'll add it to the database. --PC From crow@cs.dartmouth.edu Sat Jul 16 07:26:32 1994 Received: from sics.se by cs.dartmouth.edu (8.6.5/4.2) id HAA06444; Sat, 16 Jul 1994 07:26:28 -0400 Received: from lager.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA03083; Sat, 16 Jul 94 13:24:44 +0200 Received: by lager.sics.se (5.65+bind 1.7+ida 1.4.2/SICSclient-1.1) id AA24216 (for sasos@cs.dartmouth.edu); Sat, 16 Jul 94 13:24:43 +0200 Date: Sat, 16 Jul 1994 13:24:42 +0200 (MET DST) From: Tim Wilkinson Sender: Tim Wilkinson Reply-To: Tim Wilkinson Subject: European SASOS WWW archive To: Single Address Space Operating Systems Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I've made our local SASOS WWW archive available to the general Net. It contains much the same information as the one at Dartmouth, which we mirror, but will probably be quicker to access from European sites. To access it, use a browser such as Mosaic or Lynx and goto the URL: http://web.cs.city.ac.uk/archive/sasos/ Comments, as ever, appreciated. Tim -- Tim Wilkinson tim@sics.se [for the summer] Swedish Institute of Computer Science http://sics.se/~tim/.finger.html 16428 Kista, Stockholm, Sweden Tel: +46 8 752 1534 Fax: +46 8 751 7230 From crow@cs.dartmouth.edu Mon Jul 18 03:19:45 1994 Received: from bambam.cs.city.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id DAA12698; Mon, 18 Jul 1994 03:19:41 -0400 Received: by bambam.cs.city.ac.uk (Smail3.1.28.1 #14) id m0qPmtu-0000xMC; Mon, 18 Jul 94 08:14 BST To: citycs-list-sasos@cs.city.ac.uk Path: usenet From: njw@cs.city.ac.uk (Nick Williams) Newsgroups: citycs.list.sasos Subject: Re: European SASOS WWW archive Date: 18 Jul 1994 07:17:53 GMT Organization: Systems Architecture Research Centre, City University Lines: 19 Message-ID: References: <308ied$o8q@bambam.cs.city.ac.uk> NNTP-Posting-Host: wilma.cs.city.ac.uk In-reply-to: Tim Wilkinson's message of 16 Jul 1994 13:05:33 +0100 In article <308ied$o8q@bambam.cs.city.ac.uk> Tim Wilkinson writes: > To access it, use a browser such as Mosaic or Lynx and goto the URL: > http://web.cs.city.ac.uk/archive/sasos/ Even better, use the more complete URL of http://web.cs.city.ac.uk/archive/sasos/sasos.html which will work from any browser. Nick (aka 0.5*webmaster) -- Nick Williams, Systems Architecture Research Centre, City University, London, EC1V 0HB. UK. Web: http://web.cs.city.ac.uk/finger?njw E-mail: njw@cs.city.ac.uk (MIME and ATK) Work Telephone: +44 71 477 8551 Work Fax: +44 71 477 8587 From crow@cs.dartmouth.edu Fri Dec 9 09:54:17 1994 Received: from concorde.inria.fr by cs.dartmouth.edu (8.6.5/4.2) id JAA00690; Fri, 9 Dec 1994 09:54:15 -0500 Received: from corto.inria.fr (root@corto.inria.fr [128.93.11.2]) by concorde.inria.fr (8.6.9/8.6.9) with ESMTP id PAA24466 for ; Fri, 9 Dec 1994 15:56:15 +0100 Received: from druuna.inria.fr (druuna.inria.fr [128.93.11.40]) by corto.inria.fr (8.6.8/8.6.5) with ESMTP id PAA06893 for ; Fri, 9 Dec 1994 15:56:11 +0100 From: Marc Shapiro Received: (shapiro@localhost) by druuna.inria.fr (8.6.8/8.6.6) id PAA19827; Fri, 9 Dec 1994 15:56:11 +0100 Date: Fri, 9 Dec 1994 15:56:11 +0100 Message-Id: <199412091456.PAA19827@druuna.inria.fr> To: sasos@cs.dartmouth.edu Subject: TR on garbage collecting a SASOS The following technical report on garbage collecting a single-address-space distributed shared persistent memory is available for anonymous FTP. Larchant-RDOSS: a distributed shared persistent memory and its garbage collector Marc Shapiro (INRIA Rocquencourt and Cornell University) Paulo Ferreira (INRIA Rocquencourt) INRIA Rapport de Recherche no. 2399 and Cornell Computer Science TR94-1466 November 1994 ABSTRACT Larchant-RDOSS is a distributed shared memory that persists on reliable storage across process lifetimes. Memory management is automatic: including consistent caching of data and of locks, collecting objects unreachable from the persistent root, writing reachable objects to disk, and reducing store fragmentation. Memory management is based on a novel garbage collection algorithm, that approximates a global trace by a series of local traces, with no induced I/O or locking traffic, and no synchronization between the collector and the application processes. This results in a simple programming model, and expected minimal added application latency. The algorithm is designed for the most unfavorable environment (uncontrolled programming language, reference by pointers, distributed system, non-coherent shared memory) and should work well also in more favorable settings. (Note that this report is vastly different from the articles on a similar system, Larchant-BMX, which appeared recently at OSDI, Operating Systems Design and Implementation, and at POS, Persistent Object Systems.) Access: - in Europe, ftp://ftp.inria.fr/INRIA/Projects/SOR/RDOSS:rr2399.ps.gz - in North America, ftp://ftp.cs.cornell.edu/pub/TECH-RPT/TR94-1466.ps.Z (not yet installed as of 8-dec-94) From crow@cs.dartmouth.edu Fri Dec 9 12:57:28 1994 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.5/4.2) id MAA02335; Fri, 9 Dec 1994 12:57:28 -0500 Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id MAA28641 for ; Fri, 9 Dec 1994 12:59:31 -0500 Message-id: <9881669@dancer.Dartmouth.EDU> Date: 09 Dec 94 12:59:21 EST From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: sasos@cs.dartmouth.edu Subject: TR on garbage collecting a SASOS To: sasos@cs.dartmouth.edu [Note: The machine handling the list was being upgraded at the time this was sent, so I'm resending it. We don't expect further problems.] From: Marc Shapiro Date: Fri, 9 Dec 1994 15:56:11 +0100 Message-Id: <199412091456.PAA19827@druuna.inria.fr> To: sasos@cs.dartmouth.edu Subject: TR on garbage collecting a SASOS The following technical report on garbage collecting a single-address-space distributed shared persistent memory is available for anonymous FTP. Larchant-RDOSS: a distributed shared persistent memory and its garbage collector Marc Shapiro (INRIA Rocquencourt and Cornell University) Paulo Ferreira (INRIA Rocquencourt) INRIA Rapport de Recherche no. 2399 and Cornell Computer Science TR94-1466 November 1994 ABSTRACT Larchant-RDOSS is a distributed shared memory that persists on reliable storage across process lifetimes. Memory management is automatic: including consistent caching of data and of locks, collecting objects unreachable from the persistent root, writing reachable objects to disk, and reducing store fragmentation. Memory management is based on a novel garbage collection algorithm, that approximates a global trace by a series of local traces, with no induced I/O or locking traffic, and no synchronization between the collector and the application processes. This results in a simple programming model, and expected minimal added application latency. The algorithm is designed for the most unfavorable environment (uncontrolled programming language, reference by pointers, distributed system, non-coherent shared memory) and should work well also in more favorable settings. (Note that this report is vastly different from the articles on a similar system, Larchant-BMX, which appeared recently at OSDI, Operating Systems Design and Implementation, and at POS, Persistent Object Systems.) Access: - in Europe, ftp://ftp.inria.fr/INRIA/Projects/SOR/RDOSS:rr2399.ps.gz - in North America, ftp://ftp.cs.cornell.edu/pub/TECH-RPT/TR94-1466.ps.Z (not yet installed as of 8-dec-94) From crow@cs.dartmouth.edu Tue Dec 20 14:13:19 1994 Received: from lancashire.cs.wisc.edu by cs.dartmouth.edu (8.6.5/4.2) id OAA11715; Tue, 20 Dec 1994 14:13:18 -0500 From: talluri@cs.wisc.edu (Madhusudhan Talluri) Message-Id: <9412201915.AA00943@lancashire.cs.wisc.edu> Received: by lancashire.cs.wisc.edu; Tue, 20 Dec 94 13:15:25 -0600 Subject: Re: TR on garbage collecting a SASOS To: sasos@cs.dartmouth.edu Date: Tue, 20 Dec 1994 13:15:25 -0600 (CST) In-Reply-To: <9881669@dancer.Dartmouth.EDU> from "Preston F. Crow" at Dec 9, 94 12:59:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 282 > > Access: > - in Europe, ftp://ftp.inria.fr/INRIA/Projects/SOR/RDOSS:rr2399.ps.gz > - in North America, ftp://ftp.cs.cornell.edu/pub/TECH-RPT/TR94-1466.ps.Z > (not yet installed as of 8-dec-94) > I still cannot find the above TR. When is it due to be installed? --Madhu From crow@cs.dartmouth.edu Tue Feb 21 11:35:25 1995 Received: from dove.cf.ac.uk by cs.dartmouth.edu (8.6.5/4.2) id LAA06435; Tue, 21 Feb 1995 11:35:19 -0500 Received: from nrd2s.cf.ac.uk by dove.cf.ac.uk with SMTP (PP) id <21287-0@dove.cf.ac.uk>; Tue, 21 Feb 1995 16:34:47 +0000 Received: from NRD2S/MAILQUEUE by nrd2s.cf.ac.uk (Mercury 1.13); Tue, 21 Feb 95 16:34:56 GMT Received: from MAILQUEUE by NRD2S (Mercury 1.13); Tue, 21 Feb 95 16:34:44 GMT From: "P.I.Nicholson" To: sasos@cs.dartmouth.edu Date: Tue, 21 Feb 1995 16:34:38 GMT Subject: request for info. X-Confirm-Reading-To: "P.I.Nicholson" X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: <16F56B06DB5@nrd2s.cf.ac.uk> Please will you send me information on how to join Ian NIcholson From crow@cs.dartmouth.edu Thu Feb 23 00:12:51 1995 Received: from ogion.mcs.kent.edu by cs.dartmouth.edu (8.6.5/4.2) id AAA26654; Thu, 23 Feb 1995 00:12:50 -0500 Received: from localhost.ARPA by ogion.mcs.kent.edu (930416.SGI/92.09.25) id AA25166; Thu, 23 Feb 95 00:07:16 -0500 Message-Id: <9502230507.AA25166@ogion.mcs.kent.edu> Reply-To: sjc@mcs.kent.edu To: Andy Bond , Roy Campbell , John Carter , Ray Cline , "David W. Forslund" , Richard Freund , James Griffioen , Andrew Grimshaw , Debra Hensgen , Pete Keleher , Ted Lewis , Darrell Long , Shawn Ostermann , Larry Peterson , Paul Pierce , Peter Reiher , Vince Russo , Mukesh Singhal , Vaidy Sunderam , Jonathan Turner , Steve Wheat , Raj Yavatkar , SASOS mailing list , VSTa mailing list From: "Steve Chapin" Zevon-Of-The-Day: Accidentally Like a Martyr Subject: CFP: HICSS-29 minitrack on parallel/dist. OS Date: Thu, 23 Feb 1995 00:07:16 -0500 Sender: sjc@mcs.kent.edu Folks, Enclosed is a CFP for a minitrack that Barney Maccabe and I are running at the next HICSS. We cordially invite you to submit a paper or consider being a referee for us. C'mon out and visit Maui! Regards, sc -- Call For Papers and Referees in The Parallel and Distributed Operating Systems Minitrack of the 29th Hawaii International Conference on System Sciences, HICSS-29 Maui, Hawaii - January 3-6, 1996 ********************************************************************* We are seeking manuscripts and referees for our minitrack in Parallel and Distributed Operating Systems at HICSS-29. We are especially interested in papers in the following areas: o heterogeneous multiprocessor operating systems: program representation for multiple architectures, architecture-independent operating system services, and scheduling in heterogeneous distributed systems; o low-overhead protocols for high-speed networks: ATM networks, lightweight remote procedure call, and active messages; o parallel operating systems in general: support for repartitionable parallel architectures, parallel operating system structure, message-passing operating systems, and locking mechanisms; o distributed operating systems in general: microkernel organization, distributed deadlock detection, distributed mutual exclusion, and transaction support; o distributed shared memory: coherency mechanisms, scalable approaches to DSM, and single address space operating systems; o cache coherency in multiprocessor systems: operating system support for extensible caching policies, and new cache coherence protocols; o and scheduling in multiprocessor systems: local and global scheduling, dynamic and static scheduling, and scheduling for meta-systems. Those papers selected for presentation will appear in the Conference Proceedings, published by the IEEE Computer Society. We are finalizing arrangements for the best papers from this minitrack to appear in a special issue of IEEE Parallel and Distributed Technology. Submit your 300-word (one page) abstract to Steve Chapin (see address below). Persons interested in refereeing in these areas should contact the minitrack coordinators directly. Electronic submission of PostScript or ASCII abstracts is preferred. Details on submissions of full papers will be released at a later date. COORDINATORS ------------ Steve J. Chapin Department of Mathematics and Computer Science Kent State University Kent, OH 44242 sjc@mcs.kent.edu Arthur B. Maccabe Department of Computer Science University of New Mexico Albuquerque, NM 87131-1386 maccabe@cs.unm.edu 1995 Deadlines ************** o A 300-word abstract by March 15 o Feedback to author on abstract by April 3 o Eight copies of the manuscript by June 1 o Notification of accepted papers by August 31 o Camera-ready copies of accepted manuscripts are due by October 2 Steve Chapin Barney Maccabe sjc@mcs.kent.edu maccabe@cs.unm.edu From crow@cs.dartmouth.edu Sat Mar 18 00:08:28 1995 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.10/4.2) id AAA14335; Sat, 18 Mar 1995 00:08:27 -0500 Received: from gatekeeper.qms.com (gatekeeper.imagen.com [161.33.3.1]) by dartvax.dartmouth.edu (8.6.10+DND/8.6.9) with SMTP id AAA10810 for ; Sat, 18 Mar 1995 00:08:45 -0500 Received: from imagen.sclara.qms.com (imagen.imagen.com) by gatekeeper.qms.com (4.1/SMI-4.1) id AA18124; Fri, 17 Mar 95 20:50:40 PST Received: from sun470.rd.qms.com by imagen.sclara.qms.com (4.1/SMI-4.1) id AA09830; Fri, 17 Mar 95 20:49:42 PST Received: from jrtsparc5.qms.com by sun470.rd.qms.com (4.1/SMI-4.1) id AA09100; Fri, 17 Mar 95 22:46:20 CST Received: from jrt (slip2) by jrtsparc5.qms.com (4.1/SMI-4.1) id AA00227; Fri, 17 Mar 95 22:49:19 CST Date: Fri, 17 Mar 95 22:49:18 CST Message-Id: <9503180449.AA00227@jrtsparc5.qms.com> X-Sender: rturner@jrtsparc5 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: sasos@cs.dartmouth.edu From: rturner@qms.com (Randy Turner) Subject: SASOS prototypes I was wondering if there are any SASOS prototype distributions available for evaluating? Specifically, are any of them utilizing the MIPS R4k processor family? Thanks! Randy From crow@cs.dartmouth.edu Fri Sep 15 12:25:15 1995 Received: from kruiser.cs.vu.nl by cs.dartmouth.edu (8.6.12/4.2) id MAA27823; Fri, 15 Sep 1995 12:25:14 -0400 Received: by kruiser.cs.vu.nl (Smail3.1.28.1 #20) id m0stdb7-0003soC; Fri, 15 Sep 95 18:26 +0200 Message-Id: Date: Fri, 15 Sep 95 18:26:41 MET DST From: Andy Tanenbaum To: rem-conf@es.net, mm-announcement-list@cs.ucsd.edu, sasos@cs.dartmouth.edu Subject: SIGOPS European Workshop Announcement Call for Papers Seventh ACM SIGOPS European Workshop Systems Support for Worldwide Applications 2-4 September 1996, Connemara, Ireland In the past, each computer had its own users and jobs. The task of the operating system was to allocate resources among competing users. With the advent of LANs and the Internet, multiple computers could collaborate to per- form specialized tasks for a modest number of sophisticated users. In the future, most computers will be connected to what is often called the ``Infor- mation Superhighway.'' This as-yet-unbuilt system will allow hundreds of mil- lions of ordinary citizens to access global information and participate in applications of unprecedented scale. The requirements of the system software will change accordingly. The emphasis will shift from enforcing local kernel-user protection boundaries to enabling groups of users to collaborate and access information efficiently. New models, tools, and other software will be required. In this workshop, we will explore these issues. Possible topics include: - Wide-area distributed systems for millions of users - Tools, models and infrastructure for global applications - Life after the World Wide Web - Caching and replication - (Distributed) management of (distributed) services - Resource and information discovery services - Systems support for multimedia applications - Systems aspects of security and reliability Attendance is limited to 50 people, by invitation only. The workshop will be held at the Renvyle House Hotel in Connemara, Ireland. It is a small, secluded site on the Renvyle Peninsula, surrounded by water on three sides and 200 acres of hotel land and mountains on the remaining side. Papers will be selected on the basis of ability to foster discussion, originality, and appropriateness to the workshop topic. Accepted papers will be distributed to the workshop attendees and via the web. A few papers may be selected for publication in Operating Systems Review. For additional information, submission instructions, and photographs of the workshop site, see the workshop's web page: http://plastique.stanford.edu/sigops96/ Program chairman Program Committee --------------- ----------------- Andrew S. Tanenbaum Ozalp Babaoglu, Univ. di Bologna Dept. of Math. & Computer Science Jean Bacon, Cambridge University Vrije Universiteit Mary Baker, Stanford University De Boelelaan 1081a Yolande Berbers, Kath. Univ., Leuven 1081 HV Amsterdam,Holland Andrew Black, Oregon Graduate Inst. Email: ast@cs.vu.nl Frans Kaashoek, MIT FAX: +31 20 4447653 Barbara Liskov, MIT Karin Petersen, Xerox PARC Important dates: Willy Zwaenepoel, Rice University Position papers due: 1 March 1996 Acceptance notice: 15 May 1996 General chairman Final 8-page papers: 15 July 1996 ---------------- Workshop date: 2-4 Sept. 1996 Andrew Herbert, ANSA (ajh@ansa.co.uk) From crow@cs.dartmouth.edu Sat Sep 16 14:19:08 1995 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.6.12/4.2) id OAA12097; Sat, 16 Sep 1995 14:19:08 -0400 Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.6.12-DND/8.6.12) with SMTP id OAA30299 for ; Sat, 16 Sep 1995 14:20:35 -0400 Message-id: <19023814@dancer.Dartmouth.EDU> Date: 16 Sep 95 14:20:34 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: latest SASOS work? To: sasos@cs.dartmouth.edu It's been a while since anyone has said much on this list. I assume that this does not mean that everyone has given up on the idea of single- address-space operating systems. So what has been done in the past year? What projects are still underway? What projects have been completed? --PC From crow@cs.dartmouth.edu Fri Nov 3 21:04:50 1995 Received: from whistler.cs.washington.edu by cs.dartmouth.edu (8.7.1/4.2) id VAA19680; Fri, 3 Nov 1995 21:04:49 -0500 Received: from localhost (localhost [127.0.0.1]) by whistler.cs.washington.edu (8.6.12/7.2ws+) with SMTP id SAA07888 for ; Fri, 3 Nov 1995 18:05:11 -0800 Message-Id: <199511040205.SAA07888@whistler.cs.washington.edu> To: sasos@cs.dartmouth.edu Subject: Opal home page Date: Fri, 03 Nov 1995 18:05:10 PST From: Hank Levy Sorry to interrupt the silence on this channel, but for anyone interested, there is a web home page for the Opal OS project here at University of Washington, which is http://www.cs.washington.edu/homes/levy/opal. Through the home page you can find links to all Opal and Opal-related publications. New on the list are: - "An Operating System Structure for Wide-Address Architectures," Jeff Chase's PhD Thesis, which contains the most complete description of the Opal SASOS and its implementation. - "Global Memory Management in a Workstation Cluster," not really an SAS paper, but description of an algorithm for and implementation of network-wide memory management on a high-speed ATM LAN. - "Using Shared Memory for Read-Mostly RPC," presents some runtime mechanisms for use of cross-domain shared memory in an SASOS. For an overview of Opal, see "Sharing and Protection in a Single-Address Space Operating System." hank From crow@cs.dartmouth.edu Sat Nov 4 07:07:17 1995 Received: by cs.dartmouth.edu (8.7.1/4.2) id HAA24266; Sat, 4 Nov 1995 07:07:17 -0500 Date: Sat, 4 Nov 1995 07:07:17 -0500 From: wbc (Wayne B Cripps) Message-Id: <199511041207.HAA24266@cs.dartmouth.edu> To: sasos@cs.dartmouth.edu Subject: Sorry I apologise for the multitude of repostings - the sasos mailer got caught by one of the "features" of the newest sendmail! Wayne  From crow@cs.dartmouth.edu Wed Apr 10 02:13:03 1996 Received: from ogion.mcs.kent.edu by cs.dartmouth.edu (8.7.4/4.4) id CAA13131; Wed, 10 Apr 1996 02:12:54 -0400 Received: from localhost.ARPA by ogion.mcs.kent.edu (930416.SGI/92.09.25) id AA12835; Wed, 10 Apr 96 02:06:12 -0400 Message-Id: <9604100606.AA12835@ogion.mcs.kent.edu> Reply-To: sjc@mcs.kent.edu To: Andy Bond , Roy Campbell , John Carter , Fred Douglis , "David W. Forslund" , Richard Freund , James Griffioen , Andrew Grimshaw , Debra Hensgen , Dan Hildebrand , Krishna Kavi , Pete Keleher , Ted Lewis , Darrell Long , Kia Makki , Shawn Ostermann , Larry Peterson , Paul Pierce , Mike Quinn , Peter Reiher , Vince Russo , Eugen Schenfeld , Michael Scott , Behrooz Shirazi , "H. J. Siegel" , Mukesh Singhal , Vaidy Sunderam , Jonathan Turner , Raj Yavatkar , SASOS mailing list , VSTa mailing list , parallel-io@dartmouth.edu From: "Steve Chapin" Zevon-Of-The-Day: Stand in the Fire Subject: CFP for P&DT and IEEE TCOS special issues Date: Wed, 10 Apr 1996 02:06:11 -0400 Sender: sjc@mcs.kent.edu Greetings. Barney Maccabe and I are guest editors for an upcoming special issue of IEEE Parallel & Distributed Technology. The topic of our special issue will be Parallel and Distributed Operating Systems. I'm attaching a CFP and hope that you'll consider submitting a paper to our special issue. In addition, if you've got something that you feel isn't approriate for P&DT but you'd like to get quick turnaround on publication, I'm also putting together a special issue of the IEEE Technical Committee on Operating Systems (TCOS) newsletter on parallel/distributed OS. Regards, sc ------------------------------------------------------------------------ Steve Chapin, Asst. Prof. of CS sjc@cs.kent.edu Dept. of Math. and Computer Science voice: (330) 672-4004 x351 Kent State University FAX: (330) 672-7824 Kent, OH 44242-0001 ------------------------------------------------------------------------ Call For Articles IEEE Parallel & Distributed Technology Special Issue: Multiprocessor Operating Systems We are seeking articles for a special issue of Parallel & Distributed Technology on Multiprocessor Operating Systems. The issue will describe the current state of the art in parallel and distributed operating systems, examinine ``hot'' research topics in the area, and discuss future trends for commercial systesm. We are interested in papers in all areas of multiprocessor systems, especially the following: + heterogeneous multiprocessor operating systems: program representation for multiple architectures, and architecture-independent operating system services; + low-overhead protocols for high-speed networks: ATM networks, lightweight remote procedure call, and active messages; + parallel operating systems in general: support for repartitionable parallel architectures, parallel operating system structure, message-passing operating systems, and locking mechanisms; + distributed operating systems in general: microkernel organization, distributed deadlock detection, distributed mutual exclusion, and transaction support; + distributed shared memory: coherency mechanisms, scalable approaches to DSM, and single address space operating systems; and + scheduling in multiprocessor systems: local and global scheduling, dynamic and static scheduling, and scheduling for meta-systems. Submissions should be less than 6,000 words. We welcome descriptions of complete systems, works-in-progress, overviews of current research trends, and visions of future directions. We are particularly interested in articles regarding topics with potential for commercial and practical impact in the near future through technology transfer. Articles should be written in a lively, tutorial style. Please submit PostScript via email or, alternatively, submit eight copies to either guest editor no later than July 15, 1996. Steve J. Chapin Arthur B. Maccabe Dept. of Math. and Comp. Sci. Department of Computer Science Kent State University University of New Mexico Kent, OH 44242 Albuquerque, NM 87131-1386 sjc@mcs.kent.edu maccabe@cs.unm.edu From crow@cs.dartmouth.edu Sun May 19 22:26:49 1996 Received: from vanuata.dcs.gla.ac.uk by cs.dartmouth.edu (8.7.4/4.4) id WAA15209; Sun, 19 May 1996 22:26:48 -0400 From: miguel@dcs.gla.ac.uk Received: from chatham.dcs.gla.ac.uk by vanuata.dcs.gla.ac.uk with LOCAL SMTP (PP); Mon, 20 May 1996 03:26:36 +0100 Received: by chatham.dcs.gla.ac.uk (4.1/Dumb) id AA01482; Mon, 20 May 96 03:26:33 BST Message-Id: <9605200226.AA01482@chatham.dcs.gla.ac.uk> Subject: Posix in a SASOS?? To: sasos@cs.dartmouth.edu Date: Mon, 20 May 1996 03:26:32 +0100 (BST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, everybody. I'm wondering if somebody "out-there" could give me references to understand what is a SASOS for and the reasons why to take SASOS as a model to follow in new developments of OS. As well (and more concern with my actual interest/work) I do really apreciate references on how to map an Unix-like environment into a SASOS, or in oder words, ideas, keys to take into account for building a POSIX interface over a SASOS. Thanks ("very muchly") in advance for any possible help. From "pipes-kilts-whisky-land", -- Miguel Ansaras Phone: +44 141 3306297 (3398855 ext.6297) Computing Science Fax: +44 141 3304913 University of Glasgow Email: miguel@dcs.gla.ac.uk G12 8QQ Glasgow, Scotland WWW: http://www.dcs.gla.ac.uk/~miguel From crow@cs.dartmouth.edu Mon May 20 05:30:30 1996 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.7.4/4.4) id FAA18800; Mon, 20 May 1996 05:30:28 -0400 Received: From jungfrau.disy.cse.unsw.EDU.AU ([127.0.0.1]) By jungfrau With Smtp ; Mon, 20 May 96 19:29:59 +1000 From: Gernot Heiser To: miguel@dcs.gla.ac.uk Date: Mon, 20 May 1996 19:29:45 +1000 Message-Id: <960520092948.3613@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: Posix in a SASOS?? In-reply-to: Your message of "Mon, 20 May 1996 03:26:32 +0100." <9605200226.AA01482@chatham.dcs.gla.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: gernot@cse.unsw.edu.au Miguel Ansaras (miguel@dcs.gla.ac.uk) writes: > Hi, everybody. > > I'm wondering if somebody "out-there" could give me references > to understand what is a SASOS for and the reasons why to take > SASOS as a model to follow in new developments of OS. > > As well (and more concern with my actual interest/work) I do > really apreciate references on how to map an Unix-like > environment into a SASOS, or in oder words, ideas, keys > to take into account for building a POSIX interface over > a SASOS. Tim Wilkinson from City has shown how to do fork (which is generally considered the tough part of POSIX compliance for a SASOS). The paper "Compiling for a 64-bit Single Address Space Architectue) is available via the Angel WWW page http://web.cs.city.ac.uk/research/sarc/angel.html That page also contains links a number of other papers on SASOS in general (and Angel specifically). The Opal WWW site http://www.cs.washington.edu/homes/levy/opal/ contains more, as does the Mungi one http://www.cse.unsw.EDU.AU/~disy/Mungi.html For an introduction to SASOS try "Single Address Space Operating Systems" on this site. This also contains a brief discussion on how to achieve POSIX compliance. Gernot Heiser ,--_|\ School of Computer Science & Engineering Phone: +61 2 385 5156 / \ The University of NSW Fax: +61 2 385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v Web: http://www.cse.unsw.edu.au/~gernot NOTE: THE "385" PHONE PREFIX WILL CHANGE TO "9385" IN JULY 1996 From crow@cs.dartmouth.edu Mon May 20 08:03:38 1996 Received: from concorde.inria.fr by cs.dartmouth.edu (8.7.4/4.4) id IAA19609; Mon, 20 May 1996 08:03:37 -0400 Received: from prof.inria.fr (prof.inria.fr [128.93.11.47]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id OAA02766; Mon, 20 May 1996 14:03:36 +0200 (MET DST) Received: from timide.inria.fr (timide-f.inria.fr [193.51.192.5]) by prof.inria.fr (8.6.10/8.6.6) with ESMTP id OAA26783; Mon, 20 May 1996 14:03:33 +0200 Received: (shapiro@localhost) by timide.inria.fr (8.6.10/8.6.6) id OAA16398; Mon, 20 May 1996 14:03:33 +0200 Date: Mon, 20 May 1996 14:03:33 +0200 Message-Id: <199605201203.OAA16398@timide.inria.fr> From: Marc Shapiro To: gclist@iecc.com, sasos@cs.dartmouth.edu Subject: article You may be interested in the following article. ---------------------------------------------------------------------- Asynchronous Distributed Garbage Collection in a Cached Store Paulo Ferreira Marc Shapiro INRIA Rocquencourt, Projet SOR Asynchronous Distributed Garbage Collection in a Cached Store Larchant is a cached persistent store, combining distributed shared memory and persistence by reachability. Programs, running at different sites and/or times, share data by assigning and navigating pointers. Automatic garbage collection is essential in this context; the GC algorithms must take into account the cost of coherence and of I/O and must scale. The Larchant GC is based on local collection; it incurs no coherence or I/O overhead; it is fully asynchronous. Contributions of this work include a simple, general model of memory, applications, coherence, and GC, safety rules for asynchronous GC in the presence of possibly incoherent replicas, a technique for asynchronous GC, an implementation, and performance measurements. ---------------------------------------------------------------------- This article has been submitted for publication. It will be available for one week at the following address: ftp://alix.inria.fr/pub/larchant-submitted.ps.gz From crow@cs.dartmouth.edu Mon May 20 16:55:25 1996 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.7.4/4.4) id QAA28290; Mon, 20 May 1996 16:55:24 -0400 Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.4/8.7.3) with ESMTP id QAA01428; Mon, 20 May 1996 16:55:41 -0400 Message-Id: <199605202055.QAA01428@eros.cis.upenn.edu> To: Marc Shapiro Cc: gclist@iecc.com, sasos@cs.dartmouth.edu Subject: Re: article on distributed GC In-reply-to: Your message of "Mon, 20 May 1996 14:03:33 +0200." <199605201203.OAA16398@timide.inria.fr> Date: Mon, 20 May 1996 16:55:41 -0400 From: "Jonathan S. Shapiro" I went to hunt it down, and found a small error in Marc's URL announcement. The correct URL for the paper is: ftp://alix.inria.fr/pub/shapiro/larchant-submitted.ps.gz From crow@cs.dartmouth.edu Thu May 23 16:43:14 1996 Received: from concorde.inria.fr by cs.dartmouth.edu (8.7.4/4.4) id QAA12964; Thu, 23 May 1996 16:43:11 -0400 Received: from prof.inria.fr (prof.inria.fr [128.93.11.47]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id WAA19938; Thu, 23 May 1996 22:43:04 +0200 (MET DST) Received: from alix.inria.fr (shapiro@alix.inria.fr [128.93.11.42]) by prof.inria.fr (8.6.10/8.6.6) with ESMTP id WAA19239; Thu, 23 May 1996 22:42:58 +0200 Received: (shapiro@localhost) by alix.inria.fr (8.6.10/8.6.6) id WAA17131; Thu, 23 May 1996 22:42:56 +0200 Date: Thu, 23 May 1996 22:42:56 +0200 Message-Id: <199605232042.WAA17131@alix.inria.fr> From: Marc Shapiro To: gclist@iecc.com, sasos@cs.dartmouth.edu Subject: mistake As several of you have noted, I sent out an incorrect URL for our paper on garbage collecting a cached store. The correct URL is: ftp://alix.inria.fr/pub/shapiro/larchant-submitted.ps.gz Valid until 30 May midnight. Marc From crow@cs.dartmouth.edu Sun Dec 8 17:49:11 1996 Received: from mail.iol.co.il by cs.dartmouth.edu (8.8.3/4.4) id RAA32386; Sun, 8 Dec 1996 17:49:06 -0500 (EST) Received: from ELADBAR- (dial-3-3.slip.huji.ac.il [128.139.9.13]) by mail.iol.co.il (8.6.12/8.6.9) with SMTP id BAA21731 for ; Mon, 9 Dec 1996 01:50:52 +0200 Date: Mon, 9 Dec 1996 01:50:52 +0200 Message-Id: <199612082350.BAA21731@mail.iol.co.il> X-Sender: abn34567@mail.iol.co.il (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: sasos@cs.dartmouth.edu From: Elad Bar-Natan Subject: sites can you please recomend me on some cool sites ? thank you ! e-mail : abn34567@iol.co.il ELAD BAR-NATAN,ISRAEL. e-mail: abn34567@iol.co.il /\ /\ . . \(^_^)/ ! --- __________ / __ __ \ ( (__) (__) ) [[[---------]]] "You want the Real Thing, and I'm a diet coke, okay?" Since I have no sense of decency, all my other senses are enhanced. "I FIND IT HARD, IT WAS HARD TO FIND, OH WELL,WHATEVER,NEVERMIND" KURT COBAIN,smells like teen spirit. From crow@cs.dartmouth.edu Sun Dec 8 18:03:41 1996 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.8.3/4.4) id SAA00467; Sun, 8 Dec 1996 18:03:41 -0500 (EST) Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.7.6+DND/8.7.3) with SMTP id SAA00013; Sun, 8 Dec 1996 18:03:39 -0500 (EST) Message-id: <36910577@dancer.Dartmouth.EDU> Date: 08 Dec 96 18:03:38 EST From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: sites To: sasos@cs.dartmouth.edu, abn34567@mail.iol.co.il (Elad Bar-Natan) >can you please recomend me on some cool sites ? >thank you ! http://www.cs.dartmouth.edu/cs_archive/sasos/sasos.html That has information on this list and various related projects. If anyone here knows of other related sites, please let me know, and I'll add links. --PC Return-Path: Received: from night.dataphone.se by cs.dartmouth.edu (8.8.3/4.4) id MAA19366; Fri, 10 Jan 1997 12:33:11 -0500 (EST) Received: from tristan.phx.pp.se (dialup95-6-13.swipnet.se [130.244.95.133]) by night.dataphone.se (8.8.4/8.8.0/tri) with SMTP id SAA13497 for ; Fri, 10 Jan 1997 18:32:52 +0100 Date: Fri, 10 Jan 1997 18:17:38 +0000 (GMT) From: Johan Rydberg To: sasos@cs.dartmouth.edu Subject: 32bit SASOS? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I'm new to this list and to start some action on it I have a simple question; The projects related to this mailing list seems to be 64bit, but is it possible to create a good 32bit SASOS? -------------------------------------------------------------------- Johan Rydberg Voice: +46 485 562175 Public PGP key availible Fax : +46 485 562160 Sweden Email: jrydberg@phx.pp.se From crow@cs.dartmouth.edu Fri Jan 10 21:07:31 1997 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.3/4.4) id VAA28003; Fri, 10 Jan 1997 21:07:29 -0500 (EST) Received: From moench.disy.cse.unsw.EDU.AU By huon With Smtp ; Sat, 11 Jan 97 13:07:13 +1100 From: Gernot Heiser To: Johan Rydberg Date: Sat, 11 Jan 1997 13:07:11 +1100 Message-Id: <970111020713.11268@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "Fri, 10 Jan 1997 18:17:38 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@cse.unsw.edu.au >>>>> "JR" == Johan Rydberg writes: JR> I'm new to this list and to start some action on it I have a simple JR> question; The projects related to this mailing list seems to be JR> 64bit, but is it possible to create a good 32bit SASOS? Certainly possible (see City Uni's Angle prototype, which runs on i486s). But, other than for demonstration purposes, probably not good for much. 32-bit address spaces are barely sufficient if they are per-process. Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot From crow@cs.dartmouth.edu Fri Jan 10 23:10:10 1997 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.8.3/4.4) id XAA29454; Fri, 10 Jan 1997 23:10:09 -0500 (EST) Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.8.4+DND/8.8.4) with SMTP id XAA21904 for ; Fri, 10 Jan 1997 23:10:03 -0500 (EST) Message-id: <37640958@dancer.Dartmouth.EDU> Date: 10 Jan 97 23:10:02 EST From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: 32bit SASOS? To: sasos@cs.dartmouth.edu >But, other than for demonstration purposes, probably not good >for much. 32-bit address spaces are barely sufficient if they are >per-process. 32 bits gives you 4G, which is more swap space than any existing 32-bit system would probably use (most of the high end systems are 64-bit now), so it depends on your definition of a SASOS. If you want to include all of the secondary storage in the address space, you would have to do something really clever making everything relocatable (and probably defeating much of the purpose of having a SASOS in the process). If you only want to deal with the main memory of active processes, it's probably not too hard to do, but you don't realize most of the benefits of a full SASOS. --PC From crow@cs.dartmouth.edu Sat Jan 11 01:27:45 1997 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.3/4.4) id BAA30968; Sat, 11 Jan 1997 01:27:43 -0500 (EST) Received: From moench.disy.cse.unsw.EDU.AU By huon With Smtp ; Sat, 11 Jan 97 17:27:18 +1100 From: Gernot Heiser To: preston.crow@dancer.dartmouth.edu Date: Sat, 11 Jan 1997 17:27:13 +1100 Message-Id: <970111062714.18583@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "10 Jan 1997 23:10:02 EST." <37640958@dancer.Dartmouth.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@cse.unsw.edu.au >>>>> "PC" == Preston F Crow writes: >> But, other than for demonstration purposes, probably not good >> for much. 32-bit address spaces are barely sufficient if they are >> per-process. PC> 32 bits gives you 4G, which is more swap space than any existing 32-bit PC> system would probably use (most of the high end systems are 64-bit now), Not quite true. Shared memory supercomputers (Cray, NEC, Fujitsu) reached 4GB of physical memoryin the late '80's. These machines generally didn't have VM, but would swap whole jobs. There were certainly plenty of applications using the full 4GB of memory (and some crying out for more). Note that these machines used 32-bit addresses, even though Crays operated on 64-bit data. As long as 3 years ago, some of our servers (Sun S-1000/SS-20's) were configured with around 4GB of swap, and disk prices have dropped dramatically since, so I don't think such a configuration is all that unusual. So, even without incorporating persistent storage, a 32-bit SASOS seems to be fairly limited. And: PC> ... but you don't realize most of the benefits of a full SASOS. agreed 100% Gernot From crow@cs.dartmouth.edu Sat Jan 11 05:27:40 1997 Received: from night.dataphone.se by cs.dartmouth.edu (8.8.3/4.4) id FAA00909; Sat, 11 Jan 1997 05:27:39 -0500 (EST) Received: from tristan.phx.pp.se (dialup92-7-14.swipnet.se [130.244.92.154]) by night.dataphone.se (8.8.4/8.8.0/tri) with SMTP id LAA14782; Sat, 11 Jan 1997 11:27:23 +0100 Date: Sat, 11 Jan 1997 11:12:06 +0000 (GMT) From: Johan Rydberg To: G.Heiser@cse.unsw.edu.au cc: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-Reply-To: <970111020713.11268@cse.unsw.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 11 Jan 1997, Gernot Heiser wrote: > >>>>> "JR" == Johan Rydberg writes: > > JR> I'm new to this list and to start some action on it I have a simple > JR> question; The projects related to this mailing list seems to be > JR> 64bit, but is it possible to create a good 32bit SASOS? > > Certainly possible (see City Uni's Angle prototype, which runs on > i486s). But, other than for demonstration purposes, probably not good > for much. 32-bit address spaces are barely sufficient if they are > per-process. Isn't Angel built upon Mach? Btw, where can I get more information on this project? Is there some released source or documentation? -------------------------------------------------------------------- Johan Rydberg Voice: +46 485 562175 Public PGP key availible Fax : +46 485 562160 Sweden Email: jrydberg@phx.pp.se From crow@cs.dartmouth.edu Sat Jan 11 11:22:16 1997 Received: from relay-7.mail.demon.net by cs.dartmouth.edu (8.8.3/4.4) id LAA04657; Sat, 11 Jan 1997 11:22:15 -0500 (EST) Received: from tjwassoc.demon.co.uk ([158.152.31.107]) by relay-5.mail.demon.net id aa506771; 11 Jan 97 16:01 GMT Received: from tjwassoc.demon.co.uk (localhost [127.0.0.1]) by tjwassoc.demon.co.uk (8.7.5/8.7.3) with SMTP id PAA00291 for ; Sat, 11 Jan 1997 15:05:06 GMT Date: Sat, 11 Jan 1997 15:05:06 +0000 (GMT) From: Tim Wilkinson To: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Johan, On Sat, 11 Jan 1997, Johan Rydberg wrote: > > JR> I'm new to this list and to start some action on it I have a simple > > JR> question; The projects related to this mailing list seems to be > > JR> 64bit, but is it possible to create a good 32bit SASOS? > > > > Certainly possible (see City Uni's Angle prototype, which runs on > > i486s). But, other than for demonstration purposes, probably not good > > for much. 32-bit address spaces are barely sufficient if they are > > per-process. > > Isn't Angel built upon Mach? Btw, where can I get more information > on this project? Is there some released source or documentation? Argh!! Putting my City University hat back on for a moment, Angel was written to run either as a simulation under UNIX, or as a native kernel running on the 80486. There are various papers published on it including some performance results - you can find some of it at the City Uni. web site (http://www.soi.city.ac.uk). You can also get a copy of the sources if you're interested. I suspect the SASOS running on Mach you had in mind was Opal concocted by Jeff Chase, then at Washington Uni., now at Duke. Tim -- Tim Wilkinson Tel/Fax: +44 181 440 0658 T. J. Wilkinson & Associates, Mobile: +44 370 621006 London, UK. Email: tim@tjwassoc.demon.co.uk From crow@cs.dartmouth.edu Sat Jan 11 12:23:07 1997 Received: from relay-7.mail.demon.net by cs.dartmouth.edu (8.8.3/4.4) id MAA05432; Sat, 11 Jan 1997 12:23:07 -0500 (EST) Received: from tjwassoc.demon.co.uk ([158.152.31.107]) by relay-5.mail.demon.net id aa506740; 11 Jan 97 16:01 GMT Received: from tjwassoc.demon.co.uk (localhost [127.0.0.1]) by tjwassoc.demon.co.uk (8.7.5/8.7.3) with SMTP id PAA00295 for ; Sat, 11 Jan 1997 15:07:09 GMT Date: Sat, 11 Jan 1997 15:07:09 +0000 (GMT) From: Tim Wilkinson To: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-Reply-To: <970111062714.18583@cse.unsw.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII And they said SASOS would never take off .... now go look at JavaOS from Sun and Lucent's Inferno. Tim -- Tim Wilkinson Tel/Fax: +44 181 440 0658 T. J. Wilkinson & Associates, Mobile: +44 370 621006 London, UK. Email: tim@tjwassoc.demon.co.uk From crow@cs.dartmouth.edu Sat Jan 11 19:01:03 1997 Received: from asuvax.eas.asu.edu by cs.dartmouth.edu (8.8.3/4.4) id TAA10765; Sat, 11 Jan 1997 19:01:01 -0500 (EST) Received: from acs (rightnet.com) by asuvax.eas.asu.edu with SMTP id AA06691 (5.65c/IDA-1.4.4 for sasos@cs.dartmouth.edu); Sat, 11 Jan 1997 16:56:42 -0700 Message-Id: <32D837C2.7B7B@acm.org> Date: Sat, 11 Jan 1997 17:00:50 -0800 From: "Alan C. Skousen" Reply-To: alan.skousen@acm.org X-Mailer: Mozilla 3.01Gold (WinNT; U) Mime-Version: 1.0 To: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please describe the features of JavaOS whick make it a SASOS. Alan Skousen Tim Wilkinson wrote: > > And they said SASOS would never take off .... now go look at JavaOS from > Sun and Lucent's Inferno. > > Tim > > -- > Tim Wilkinson Tel/Fax: +44 181 440 0658 > T. J. Wilkinson & Associates, Mobile: +44 370 621006 > London, UK. Email: tim@tjwassoc.demon.co.uk From crow@cs.dartmouth.edu Sat Jan 11 19:09:14 1997 Received: from whistler.cs.washington.edu by cs.dartmouth.edu (8.8.3/4.4) id TAA10784; Sat, 11 Jan 1997 19:09:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with SMTP id QAA08953; Sat, 11 Jan 1997 16:09:04 -0800 Message-Id: <199701120009.QAA08953@whistler.cs.washington.edu> To: alan.skousen@acm.org cc: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "Sat, 11 Jan 1997 17:00:50 PST." <32D837C2.7B7B@acm.org> Date: Sat, 11 Jan 1997 16:09:04 PST From: Hank Levy > Please describe the features of JavaOS whick make it a SASOS It has only one address space :). Actually, as far as I know (not much), it looks quite a lot like Pilot -- single address space with language-based protection. hank From crow@cs.dartmouth.edu Sat Jan 11 22:37:13 1997 Received: from asuvax.eas.asu.edu by cs.dartmouth.edu (8.8.3/4.4) id WAA12947; Sat, 11 Jan 1997 22:37:12 -0500 (EST) Received: from acs (ss5-07.inre.asu.edu) by asuvax.eas.asu.edu with SMTP id AA12326 (5.65c/IDA-1.4.4 for sasos@cs.dartmouth.edu); Sat, 11 Jan 1997 20:32:59 -0700 Message-Id: <32D86A74.11E6@acm.org> Date: Sat, 11 Jan 1997 20:37:08 -0800 From: "Alan C. Skousen" Reply-To: alan.skousen@acm.org X-Mailer: Mozilla 3.01Gold (WinNT; U) Mime-Version: 1.0 To: sasos@cs.dartmouth.edu Subject: JavaOS References: <199701120009.QAA08953@whistler.cs.washington.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any advanced features like a single distributed address space? ACS Hank Levy wrote: > > > Please describe the features of JavaOS whick make it a SASOS > > It has only one address space :). > > Actually, as far as I know (not much), it looks quite a lot > like Pilot -- single address space with language-based > protection. > > hank From crow@cs.dartmouth.edu Sun Jan 12 01:08:43 1997 Received: from organon.serpentine.com by cs.dartmouth.edu (8.8.3/4.4) id BAA14778; Sun, 12 Jan 1997 01:08:40 -0500 (EST) Received: (from bos@localhost) by organon.serpentine.com (8.7.5/8.7.3) id WAA10453; Sat, 11 Jan 1997 22:08:27 -0800 (PST) Date: Sat, 11 Jan 1997 22:08:27 -0800 (PST) From: "Bryan O'Sullivan" Message-Id: <199701120608.WAA10453@organon.serpentine.com> To: alan.skousen@acm.org Cc: sasos@cs.dartmouth.edu Subject: JavaOS In-Reply-To: <32D86A74.11E6@acm.org> References: <199701120009.QAA08953@whistler.cs.washington.edu> <32D86A74.11E6@acm.org> X-PGP-Key-Fingerprint: E3 85 A2 AF DA 32 68 E5 D6 66 B9 82 00 A3 FB F6 X-PGP-Key-Location: http://www.serpentine.com/~bos/pgp-public-key.txt a> Any advanced features like a single distributed address space? No. JavaOS provides just enough functionality to get a Java Virtual Machine running, and nothing else. So, for example, there is no virtual memory, nor is there a filesystem. In other words, while JavaOS addresses its task with perfect adequacy, I wouldn't go trumpeting it as a SASOS-made-flesh. From: Marty Fouts To: bos@serpentine.com CC: alan.skousen@acm.org, sasos@cs.dartmouth.edu In-reply-to: <199701120608.WAA10453@organon.serpentine.com> (bos@serpentine.com) Subject: Re: JavaOS perhaps JavaOS is the illusive femto-kernel? or maybe the ucsd p-code engine reincarnated? marty From crow@cs.dartmouth.edu Sun Jan 12 11:05:45 1997 Received: from relay-7.mail.demon.net by cs.dartmouth.edu (8.8.3/4.4) id LAA20927; Sun, 12 Jan 1997 11:05:44 -0500 (EST) Received: from tjwassoc.demon.co.uk ([158.152.31.107]) by relay-5.mail.demon.net id aa526080; 12 Jan 97 15:50 GMT Received: from tjwassoc.demon.co.uk (localhost [127.0.0.1]) by tjwassoc.demon.co.uk (8.7.5/8.7.3) with SMTP id PAA00247 for ; Sun, 12 Jan 1997 15:49:12 GMT Date: Sun, 12 Jan 1997 15:49:12 +0000 (GMT) From: Tim Wilkinson To: Single Address Space Operating Systems Subject: Re: JavaOS In-Reply-To: <199701120625.WAA01521@bozeman.hpl.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 11 Jan 1997, Marty Fouts wrote: > or maybe the ucsd p-code engine reincarnated? This'd get my vote - only which much better marketing and a silly coffee cup symbol. Tim -- Tim Wilkinson Tel/Fax: +44 181 440 0658 T. J. Wilkinson & Associates, Mobile: +44 370 621006 London, UK. Email: tim@tjwassoc.demon.co.uk From crow@cs.dartmouth.edu Mon Jan 13 03:18:09 1997 Received: from inf.ethz.ch by cs.dartmouth.edu (8.8.3/4.4) id DAA00032; Mon, 13 Jan 1997 03:18:05 -0500 (EST) From: muller@inf.ethz.ch Received: from lillian.inf.ethz.ch (root@lillian-ics.inf.ethz.ch [129.132.134.49]) by inf.ethz.ch (8.6.10/8.6.10) with ESMTP id JAA03807 for ; Mon, 13 Jan 1997 09:17:57 +0100 Received: from meadow.inf.ethz.ch (meadow.inf.ethz.ch [129.132.134.62]) by lillian.inf.ethz.ch (8.6.10/8.6.10) with SMTP id JAA05797 for sasos@cs.dartmouth.edu; Mon, 13 Jan 1997 09:12:19 +0100 Date: Mon, 13 Jan 1997 09:12:19 +0100 Message-Id: <199701130812.JAA05797@lillian.inf.ethz.ch> X-Mailer: Mail for Oberon (ejz) To: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? Johan Rydberg wrote: > The projects related to this mailing list seems to be > 64bit, but is it possible to create a good 32bit SASOS? I think ETH's Oberon system qualifies as a 32-bit SASOS. The original version is described in: "Project Oberon -- The Design of an Operating System and Compiler", N. Wirth and J. Gutknecht, Addison-Wesley, 1992. ISBN 0-201-54428-8 You can find a native PC-based implementation at: ftp://ftp.inf.ethz.ch/pub/Oberon/System3/Native/ The programming language Oberon is described in: "Programming in Oberon -- Steps beyond Modula-2", M. Reiser and N. Wirth, Addison-Wesley, 1992. (also in German) ISBN 0-201-56543-9 -- Pieter -- Pieter Muller, Institute for Computer Systems, ETH Zurich "http://www-cs.inf.ethz.ch/~muller/" pjm@acm.org From crow@cs.dartmouth.edu Mon Jan 13 09:56:25 1997 Received: from mail.cs.utexas.edu by cs.dartmouth.edu (8.8.3/4.4) id JAA04603; Mon, 13 Jan 1997 09:56:21 -0500 (EST) Received: from roar.cs.utexas.edu (wilson@roar.cs.utexas.edu [128.83.158.31]) by mail.cs.utexas.edu (8.8.4/8.8.4) with ESMTP id IAA22670; Mon, 13 Jan 1997 08:55:50 -0600 (CST) Received: by roar.cs.utexas.edu (8.8.4/Client-1.5) id IAA27285; Mon, 13 Jan 1997 08:55:48 -0600 (CST) Message-Id: <199701131455.IAA27285@roar.cs.utexas.edu> From: wilson@cs.utexas.edu (Paul R. Wilson) Date: Mon, 13 Jan 1997 08:55:47 -0600 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Johan Rydberg Subject: Re: 32bit SASOS? Cc: sasos@cs.dartmouth.edu >From sasos-request@cs.dartmouth.edu Fri Jan 10 11:58:35 1997 > >I'm new to this list and to start some action on it I have a simple >question; The projects related to this mailing list seems to be >64bit, but is it possible to create a good 32bit SASOS? You could build an excellent 32-bit SASOS with pointer swizzling at page fault time, as used in the Texas persistent store or Object Design's Object Store. Pointer swizzling at page fault time lets you have an arbitrarily large address space on top of normal-sized hardware, and does it efficiently. Pointers in a page are translated into the hardware-supported format when a page is faulted into memory (or into a traditional VM from a persistent store), so there's no overhead at every pointer use as there is in fine-grained schemes. The cost of swizzling pointers is small relative to I/O costs, so you don't lose much even when you're paging things in the first time. Please have a look at our papers on Texas and pointer swizzling (available from http://www.cs.utexas.edu/users/oops/). Anybody who thinks you need 64-bit hardware to build a good large-address-space SASOS *really* should read these papers. (The Opal group initially thought that there was a conflict between an Opal-style SASOS and Texas-style swizzling, but there's not---they'd go together quite well.) This scheme can even be used to support a flat address space across machines with different hardware word sizes. For example, 64-bit machines could share a 64-bit address space directly using the usual mapping techniques, but 32-bit machines on the same network could share the same data, swizzling the 64-bit pointers to 32-bit virtual addresses as pages are faulted in. Pointer swizzling at page fault time has been very successful in persistent stores---Texas and ObjectStore are the fastest persistent stores in the world, for most apps. ObjectStore is also the most successful commercial persistent store. Both work with normal C++ compilers on normal operating systems. It's a shame that most OS people don't recognize that the pointer swizzling techniques are basic architectural addressing tricks, and are equally applicable to operating systems. BTW, the pointer swizzling can be done outside the kernel---in Texas and ObjectStore, it's done by a library linked into the application, using normal OS's virtual memory mapping and protection facilities. Any reasonable kernel for a SASOS will almost certainly provide similar functionality. For a SASOS, you'd probably want to provide swizzling outside the kernel, but in a standard layer below normal apps. Pointer swizzling at page fault time does NOT require custom compilers, as fine-grained swizzling techniques do. You only need to be able to decode the layouts of objects, which you can do from the debugging output of normal compilers. Texas comes with a "type descriptor generator" that can decode several compilers' debug output and generate the type descriptors needed for swizzling, or for GC's, etc. Texas is free under the GNU Library GPL, which is less restrictive than the normal GPL. If anybody wants to use it in a SASOS, please do. I think it would be an excellent idea, and the code is free for the taking. From crow@cs.dartmouth.edu Mon Jan 13 11:44:16 1997 Received: from ebt-inc.ebt.com by cs.dartmouth.edu (8.8.3/4.4) id LAA06496; Mon, 13 Jan 1997 11:44:16 -0500 (EST) Received: from nathaniel.ebt (nathaniel [198.112.118.86]) by ebt-inc.ebt.com (8.6.12/8.6.9) with ESMTP id LAA05811 for ; Mon, 13 Jan 1997 11:42:59 -0500 Received: by nathaniel.ebt (SMI-8.6/SMI-SVR4) id LAA16837; Mon, 13 Jan 1997 11:42:00 -0500 Date: Mon, 13 Jan 1997 11:42:00 -0500 From: gtn@ebt.com (Gavin Nicol) Message-Id: <199701131642.LAA16837@nathaniel.ebt> To: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? Hmm I couldn't find the source for Angel that Tim alluded to.. From crow@cs.dartmouth.edu Mon Jan 13 22:49:08 1997 Received: from mail.cs.utexas.edu by cs.dartmouth.edu (8.8.3/4.4) id WAA18910; Mon, 13 Jan 1997 22:49:06 -0500 (EST) Received: from roar.cs.utexas.edu (wilson@roar.cs.utexas.edu [128.83.158.31]) by mail.cs.utexas.edu (8.8.4/8.8.4) with ESMTP id SAA12906; Mon, 13 Jan 1997 18:41:03 -0600 (CST) Received: by roar.cs.utexas.edu (8.8.4/Client-1.5) id SAA29292; Mon, 13 Jan 1997 18:41:01 -0600 (CST) Message-Id: <199701140041.SAA29292@roar.cs.utexas.edu> From: wilson@cs.utexas.edu (Paul R. Wilson) Date: Mon, 13 Jan 1997 18:41:01 -0600 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Jonathan S. Shapiro" Subject: Re: 32bit SASOS? Cc: sasos@cs.dartmouth.edu >A segment may include as a subsegment a "window" into some other segment. >Thus, one might construct a very large memory segment to >contain a database, >and have the 32-bit address space segment contain several 4 >megabyte windows onto the larger segment. > >The disadvantage to such "windows" is that one must now explicitly manage >address >translation in software (what Paul has referred to as >swizzling/unswizzling). Right. The point of pointer swizzling at page fault time is just to automate this process. It's compatible with systems such as yours, or with OPAL-style segments that can be in multiple overlapping protection domains. (ObjectStore has a notion of segments that's similar to Opal's.) >On a 64 bit system, this issue is obviously much less of a problem. >Fault containment and recovery, however, suggest that one does not in practice >want to build arbitrary pointer relationships. It is better (particularly in >large spaces) to build subspaces that are densely interconnected by (possibly >swizzled) pointers and explicitly manage the cross-space interconnections >with some sort of software-managed pointer. Even if you don't need to >swizzle, such a discipline is imperative for recovery. Too true. In general, you need to partition data and control dependencies between partitions for all kinds of reasons. Several p-stores let you do this. (E.g., Mneme has "files" that are roughly like Opal or ObjectStore "segments". I'm not sure where this idea was first explicated, but the vague kernel of the idea is ancient, Moss made it general, explicit and clear in Mneme, and now even commercial systems do it.). >The single level store approach more or less lets you have it both ways. >You can build SASOS subsystems if you like, but you don't get mired in such >issues as fault containment, redundancy, configuration management, and >confinement in doing so. It's far from perfect, but worth thinking about >in connection with SASOS ideas. These are definitely crucial issues which don't get nearly enough attention, because most of us are mired in interesting lower level issues. I'd just like to point out that there are plenty of cases where it's useful to a have a flat pointer model, even if the pointed-to storage may be inaccessible, protected, or even unreliable in the general case. Policy-oriented segments should not be equated with addressing segments. The concepts are orthogonal, and it's not hard to make them pretty much orthogonal in an implementation. (Warning: extended example coming... but I think it's worth thinking about particular "hard" apps that are representative of what computers are going to be used for by the time our research makes it into the world.) For example, for a planned geographically distributed VR app I'd like to support, the shared hunks of the virtual world are represented as big BSP trees (binary space partitioning trees) that are read-only from the point of view of each client's rendering engine. The usual operating mode is that every fifteenth of a second, the updated parts of the BSP tree are multicast (from servers that manage hunks of the virtual world) to the interested clients that manage observer's points of view. Then each client does a BSP tree merge of local data with this updated global data, creating a new BSP tree to render from. In this app, it's very nice if you can have direct pointers from transient local data to the (local copies of) multicast global data, so that you can do an incredibly fast BSP tree merge, and end up with a the local version of the tree sharing structure with the shared world tree. That is, the new tree you create each fifteenth of a second has lots of pointers to subtrees of the "world" tree. You don't want to mess up the elegance and speed of heavily optimized BSP tree merges by having two different kinds of pointers, with the pointers to "foreign" data being more expensive to use, or complicating your code, which is very, very tweaked. For this application---and I think many real and interesting applications---it's fairly easy for the programmer to handle the large-granularity operations, and then assume that fine-granularity code works as usual, per *obvious* limitations. In this case, the programmer of the client must know that the BSP tree merge can't be done until the multicast data is available, i.e., the next 1/15 sec. pulse. The programmer can just think "wait until the data are received" and then just go ahead and do a normal BSP tree merge (in, say, C++) with no concern about weird pointer representations, distinctions between local and remote data, or segmented addressing. It's all just data structures assumed to be in memory, even they weren't actually in memory 10ms before. The programmer also knows that if the relevant parts of the global BSP tree aren't actually available when the merge is done, the merge will fail. But that's okay, because that's intrinsic to the nature of the application---you can't afford to send all of the data everywhere, and if you send the wrong data, the client will fail, no matter what the programming model. You can't page the data in, because the roundtrips will kill you. (It has to be a push architecture, guided by a little ahead-of-time pulling when the clients tell the server roughly where the user will be in the virtual world at the next cycle.) Conventional DSM or transactions won't cut it, because somebody has to hand-code the code that decides what to ship where, and when---but flat addressing is still very nice. Another thing that's nice about having a flat address space model for the normal programming tasks is that you can automatically ensure that many such errors are automatically detected, or at least vaguely comprehensible. If you traverse a pointer to a part of the shared-world BSP tree that isn't locally resident, you could get a memory error Then you know it's time to debug the code that multicasts that data to "interested" clients. (Also notice that in this case, you can't afford to be stuck with a general-purpose recovery mechanism and its overheads. You can't even consider doing a global rollback for a client failure. When a client fails, there's little point in rolling back most of its state---it must recover forward to the next 1/15 sec. pulse, using an intrinsically application-specific protocol to figure out its new state without confusing other clients too much. Trying to recover an old state from disk may be prohibitively expensive, and mostly pointless.) The bottom line, for me, is that flat addressing can be implemented cheaply, but protection, sharing, and fault tolerance are intrinsically application-dependent. (At least if you want good performance for most interesting apps, which are increasingly likely to be distributed, fault-tolerant, and real-time.) I think it turns out that flat addressing is a nice win for the normal algorithmic parts of programs, and coarse-grained control of "blobs o' memory" is usually convenient for resource and dependency management. Programmers can introduce bad dependencies with across those units if they're careless, but that's usually a better tradeoff than having them build those abstractions themselves out of fine-grained mechanisms. The latter results in a mess of inconsistent programming styles and data formats. Fine-grained protections, etc., are valuable, and can be made surprisingly cheap (as in EROS), but for most parts of most apps, coarse grained stuff works great and can be *very* fast, with zero overhead the the usual case. You want both---implemented at different levels of the system, but universally available. So I think it's important for an OS to provide a simple flat-address-space programming model, uniformly, to almost all applications. It's not so obvious that this should be done in the kernel, and I suspect it shouldn't. (E.g., Opal or EROS could provide it on 32-bit hardware using swizzling, even if built on plain 32-bit Mach or L4 or the EROS kernel or whatever.) What's important is that it should be the default way of doing things at the "normal" programming level, so that you have a sane system-wide programming model. I don't think the kernel should commit the whole system to 64-bit hardware (which is limited anyway) even if it's optimized for that. Tentatively, I'd guess that the Right Thing would be something very roughly Opal-like built on top of something very roughly EROS kernel-like, with something roughly Texas-like in between to avoid overcommitting to particular hardware. Then you'd have simple economical flat memory abstractions for normal programming, fairly cheap fine-grained capabilities when you really need them, and the ability to do it all quite well on heterogeneous standard hardware. Does this sound reasonable? (Comments welcome.) In pragmatic terms, I think there's a problem that it's just easier to assume fairly heterogeneous 64-bit hardware. Most people building experimental systems don't want to build the whole stack I outlined above, so they collapse levels. But I think it's worth considering more levels, because hardware-independent addressing is not nearly as difficult or expensive as is widely believed. If any of these pretty new SASOS systems makes it out of the experimental world and into serious use, a little attention to hardware independence may make the next step of development much easier. Being able to share data across heterogeneous (i.e., real) networks would be a *big* plus in convincing the world that this was relevant technology. (smiley mode on, sort of:) Many years from now, there'll still be a *lot* of those wearable 1000 MHz Pentium Pro MMX (32-bit) systems that people are quite, um, attached to. Gotta be compatibly backwards with those. With pointer swizzling at page fault time, you can define data formats so that data can be accessed by client programs running on entirely different operating systems, as well as different hardware---e.g., you can support legacy Intel computers and NT apps reasonably even if all of the cool computers run your 64-bit operating system on 64-bit machines. With a little recompilation, you'll be able to keep those NT apps hapy on any machine. And when those nifty 128-bit machines come along, you'll be ready---or maybe you won't even need them. From crow@cs.dartmouth.edu Mon Jan 13 23:41:46 1997 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.8.3/4.4) id XAA20430; Mon, 13 Jan 1997 23:41:43 -0500 (EST) Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.6/8.7.3) with ESMTP id PAA00151; Mon, 13 Jan 1997 15:37:08 -0500 Message-Id: <199701132037.PAA00151@eros.cis.upenn.edu> To: wilson@cs.utexas.edu (Paul R. Wilson) cc: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "Mon, 13 Jan 1997 08:55:47 CST." <199701131455.IAA27285@roar.cs.utexas.edu> Date: Mon, 13 Jan 1997 15:37:08 -0500 From: "Jonathan S. Shapiro" In message <199701131455.IAA27285@roar.cs.utexas.edu>, Paul R. Wilson writes: > You could build an excellent 32-bit SASOS with pointer swizzling > at page fault time, as used in the Texas persistent store or > Object Design's Object Store. If you're in a position to wait until roughly the end of March, you might have a look at EROS. EROS is a pure capability system that puts the "single address space" at the object layer by means of a capability-addressed single level store. [Where it belongs -- oops, wrong list:-)]. Much of the convenience of the SASOS approach comes from two facts unrelated to the "single address space" property: 1. There is a single level store -- in most of the SASOS systems I have heard about, programs can ignore the problem of backing memory with a file, or can at least push it off to some backing store manager. The end result is that the application need not stand on its head to manage file reads and writes for data persistence. 2. Expressing sharing in terms of memory abstractions (which is what programs want to manipulate) is much more convenient than expressing them in terms of files. Together, these facts make representation optimizations (i.e. sharing memory regions) very simple. Neither of these advantages requires a single virtual address space. In the EROS system, there is a persistent single-level store that is organized into data pages (size defined by the processor architecture) and capability pages (16 caps per capage). These can be glued together to form memory objects, processes, etc., ALL of which are transparently and recoverably persistent (i.e. a process really IS an object in this system). Because the fundamental unit of data storage is the data page, EROS has much of the feel of SASOS systems. EROS programs can arrange to share subspaces. If they like, they can do so at the same virtual address to preserve embedded pointers. For reasons of internal structuring, it is particularly efficient to share subspaces at addresses that are congruent mod 0 to (16^k * pgsz) for some k >= 0 (doing so allows the entire mapping data structure to be shared in addition to the underlying data). In the current implementation, memory segments may be as large as 2^96 bytes. The process address space is a 2^32 (2^64 on 64 bit systems) window onto such a segment beginning at offset 0. A segment may include as a subsegment a "window" into some other segment. Thus, one might construct a very large memory segment to contain a database, and have the 32-bit address space segment contain several 4 megabyte windows onto the larger segment. The disadvantage to such "windows" is that one must now explicitly manage address translation in software (what Paul has referred to as swizzling/unswizzling). On a 64 bit system, this issue is obviously much less of a problem. Fault containment and recovery, however, suggest that one does not in practice want to build arbitrary pointer relationships. It is better (particularly in large spaces) to build subspaces that are densely interconnected by (possibly swizzled) pointers and explicitly manage the cross-space interconnections with some sort of software-managed pointer. Even if you don't need to swizzle, such a discipline is imperative for recovery. The single level store approach more or less lets you have it both ways. You can build SASOS subsystems if you like, but you don't get mired in such issues as fault containment, redundancy, configuration management, and confinement in doing so. It's far from perfect, but worth thinking about in connection with SASOS ideas. Further information on EROS can be found by way of my home page: http://www.cis.upenn.edu/~shap Jonathan From crow@cs.dartmouth.edu Tue Jan 14 04:20:50 1997 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.8.3/4.4) id EAA24401; Tue, 14 Jan 1997 04:20:50 -0500 (EST) Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.6/8.7.3) with ESMTP id EAA10214; Tue, 14 Jan 1997 04:15:08 -0500 Message-Id: <199701140915.EAA10214@eros.cis.upenn.edu> To: wilson@cs.utexas.edu (Paul R. Wilson) cc: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "Mon, 13 Jan 1997 18:41:01 CST." <199701140041.SAA29292@roar.cs.utexas.edu> Date: Tue, 14 Jan 1997 04:15:08 -0500 From: "Jonathan S. Shapiro" I have taken the liberty of "reducing" Paul's message... :-) > ... flat addressing can be implemented cheaply, but protection, > sharing, and fault tolerance are intrinsically > application-dependent. (At least if you want good performance for > most interesting apps, which are increasingly likely to be distributed, > fault-tolerant, and real-time.) Fault tolerance in a SASOS raises some challenges, but the part that I really don't see how to handle is fault containment. One of the things that is possible (actually quite straightforward) in EROS is to *prove* that a program has no overt outbound channels. One therefore knows that this program's errors cannot impact unrelated programs. In a nutshell, it's a reflexive transitive closure argument on the state reachable via the initial capabilities. Can anyone shed some light on how one might approach confinement proofs in the context of a SASOS? If you are not familiar with confinement issues, Butler Lampson's letter to OSR defining the term and describing the issues can be found on the KeyKOS home page at http://www.cis.upenn.edu/~KeyKOS Jonathan From crow@cs.dartmouth.edu Tue Jan 14 09:40:00 1997 Received: from mail.cs.utexas.edu by cs.dartmouth.edu (8.8.3/4.4) id JAA28067; Tue, 14 Jan 1997 09:39:59 -0500 (EST) Received: from roar.cs.utexas.edu (wilson@roar.cs.utexas.edu [128.83.158.31]) by mail.cs.utexas.edu (8.8.4/8.8.4) with ESMTP id IAA00896; Tue, 14 Jan 1997 08:39:40 -0600 (CST) Received: by roar.cs.utexas.edu (8.8.4/Client-1.5) id IAA00511; Tue, 14 Jan 1997 08:39:38 -0600 (CST) Message-Id: <199701141439.IAA00511@roar.cs.utexas.edu> From: wilson@cs.utexas.edu (Paul R. Wilson) Date: Tue, 14 Jan 1997 08:39:36 -0600 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Jonathan S. Shapiro" Subject: Re: 32bit SASOS? Cc: sasos@cs.dartmouth.edu >Fault tolerance in a SASOS raises some challenges, but the part that I >really don't see how to handle is fault containment. One of the >things that is possible (actually quite straightforward) in EROS is to >*prove* that a program has no overt outbound channels. One therefore >knows that this program's errors cannot impact unrelated programs. In >a nutshell, it's a reflexive transitive closure argument on the state >reachable via the initial capabilities. > >Can anyone shed some light on how one might approach confinement >proofs in the context of a SASOS? For Opal, I'm not clear on what the problem is. Opal has capabilites and overlapping protection domains, so I'd think you could do the same basic sorts of things you'd do in other capability-based systems, like EROS. You can have capabilities on blobs of data (segments) and refuse to grant access except within certain protection domains. To confine a program, you should be able to construct a protection domain with no writable segments that are visible to anyone except the calling program, avoid giving it any capabilities it could use to output data to third parties, and then invoke the callee in the normal way. The same capability-based structuring techniques that work in EROS should work in Opal. The main difference is that *if* you have a capability for a segment that lets you map that segment into a particular protection domain, it appears as part of a flat address space. As I understand it, Opal and EROS are similar in that there are two basic ways of communicating information across segments: by straightforward invocation through capabilities, and by using a capability to map a segment's memory into a protection domain. (In the former case, you can have a rich set of methods that give you lots of control over exactly what services are provided and what data is exposed, where in the latter case you just get to to control readability and writability on blobs of fine-grained objects at a whack.) The main difference is that in EROS, what you're mapping is segments in a segmented address space, but in Opal the "segments" are logical segments of a flat address space. (And that could be generalized to allow discontiguous "segments", which seems like a good idea.) They're just there for access policy, not for addressing mechanisms. I'm not saying that Opal offers all of the well-thought-out security features of Eros, or that it in fact has a trustworthy kernel, or that performance for capability-intensive programs is anywhere near as good. It just seems that the basic approach of using overlapping protection domains and a flat address space seems applicable to seriously security-oriented systems. Once you start granting access to memory segments, you can make it much nicer by providing a flat address space. The main difference I see in terms of security is that by exposing a segment's position in the flat address space, you may increase the variety of possible covert channels. But if you're that worried about covert channels, you're probably not going to let people map segments very freely anyway. The secure apps will have their fine-grained data hidden in protection domains that aren't accessible to their callers or callees. (I'm no expert on Opal, or EROS, and certainly not on security in general, so correction and comments are very welcome.) From crow@cs.dartmouth.edu Tue Jan 14 15:32:19 1997 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.8.3/4.4) id PAA02505; Tue, 14 Jan 1997 15:32:16 -0500 (EST) Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.6/8.7.3) with ESMTP id PAA12063; Tue, 14 Jan 1997 15:26:22 -0500 Message-Id: <199701142026.PAA12063@eros.cis.upenn.edu> To: wilson@cs.utexas.edu (Paul R. Wilson) cc: sasos@cs.dartmouth.edu Subject: Capbilities, SASOS, and Confinement In-reply-to: Your message of "Tue, 14 Jan 1997 08:39:36 CST." <199701141439.IAA00511@roar.cs.utexas.edu> Date: Tue, 14 Jan 1997 15:26:22 -0500 From: "Jonathan S. Shapiro" > The same capability-based structuring techniques that work in > EROS should work in Opal. The main difference is that *if* you > have a capability for a segment that lets you map that segment > into a particular protection domain, it appears as part of a > flat address space. This may be the crux of my confusion. I tend to forget to distinguish between mapping and protection. Because the issue rests on a shift in terminology, let me try to define things carefully. In a conventional, non-segmented system, when we say "address space", we mean a set of pairs of the form ( virtual page address, (physical page address, {R,W,V}) ) Where by 'V' I mean "valid". It seems to me that the name "single address space" is unfortunate. If I understand things, the SASOS idea at it's heart is to break this set into two mappings, one describing the mapping of addresses and the other describing the mapping of access rigts. The address mapping is a set of pairs: ( virtual page number, physical page number ) The access mapping is also a set of pairs: ( virtual page number, {R, W, V} ) On most hardware, the implementation has to be done using multiple address spaces. This isn't quite a pure capability model, in that the "names" (addresses) are forgeable -- I recognize that the (name, protection) pair is not forgeable. Most SASOS's finess this by first mapping the address to a segment (perhaps called a memory object or a mapping), which has an unforgeable name. One beauty of the pure capability model is the closure property. Given an initial set of capabilities, one can perform a transitive closure operation to determine the reachable set of objects. So long as the set does not include the authority to amplify the initial set, one can then assert that the set is closed with respect to addition. This is the crux of the confinement proof. When names and authorities become separated as in a SASOS, one shortly becomes tempted to introduce an operation that allows one party to "publish" access rights to an object. Examples of such operations in UNIX include chmod, chgrp, chown, creat, write, open, .... in a SASOS, one could imagine an option to the map operation MAP_PUBLIC, which meant "make this mapping visible to anyone". Such an operation violates the closure argument, which breaks the confinement and fault containment proof. It remains possible to buid fault contained systems, but it is now impossible to prove that they are fault contained. Provided that Opal (insert your SASOS here) lacks any such operation, I don't see a problem with the closure argument. Rather than let this grow long, I'll address some of Paul's other comments in a separate note. > The main difference I see in terms of security is that by exposing > a segment's position in the flat address space, you may increase > the variety of possible covert channels... Most of the world has given up on this problem, but before I let it go let me point out that the channel in question is surprisingly high bandwidth. Given a mapping operation that lets me say "map it here or don't map it at all", and prior collusion concerning three "leak addresses", one can leak at least one bit in something like four faults (two page signals the bit, the third provides an ACK. I didn't actually think through the fault count, so I might be off by a factor of two here). On a current generation Pentium, a page fault can be handled in something on the order of 3 us. That's [1/(3 * 10^-9)] / nfaults bits per second. That is certainly more than (1 / (1 * 10^-8)) bytes per second, which is quite a lot. I haven't checked the arithmetic, but I think you see the point. With covert channels this wide, one begins to wonder if worrying about OVERT channels is worth the bother -- which is why I am more concerned in practice about fault containment rather then confinement. Jonathan From crow@cs.dartmouth.edu Tue Jan 14 16:24:59 1997 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.3/4.4) id QAA03530; Tue, 14 Jan 1997 16:24:41 -0500 (EST) Received: From moench.disy.cse.unsw.EDU.AU By huon With Smtp ; Wed, 15 Jan 97 08:24:09 +1100 From: Gernot Heiser To: wilson@cs.utexas.edu (Paul R. Wilson) Date: Wed, 15 Jan 1997 08:24:07 +1100 Message-Id: <970114212408.19824@cse.unsw.edu.au> cc: "Jonathan S. Shapiro" , sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "Tue, 14 Jan 1997 08:39:36 MDT." <199701141439.IAA00511@roar.cs.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@unsw.edu.au >>>>> "PRW" == Paul R Wilson writes: >> Can anyone shed some light on how one might approach confinement >> proofs in the context of a SASOS? PRW> For Opal, I'm not clear on what the problem is. Opal has capabilites PRW> and overlapping protection domains, so I'd think you could do the same PRW> basic sorts of things you'd do in other capability-based systems, like PRW> EROS. PRW> You can have capabilities on blobs of data (segments) and refuse PRW> to grant access except within certain protection domains. PRW> To confine a program, you should be able to construct a protection PRW> domain with no writable segments that are visible to anyone except PRW> the calling program, avoid giving it any capabilities it could use PRW> to output data to third parties, and then invoke the callee in the PRW> normal way. You'd also have to lock the protection domain, i.e. disallow attaching further segments. Otherwise the untrusted program could attach a writable segment, the capability of which it has hidden in its code. That's essentially what's proposed (but not yet implemented) in Mungi. -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot From crow@cs.dartmouth.edu Tue Jan 14 16:59:33 1997 Received: from halifax.syncomas.com by cs.dartmouth.edu (8.8.3/4.4) id QAA03883; Tue, 14 Jan 1997 16:59:04 -0500 (EST) Received: (from shap@localhost) by halifax.syncomas.com (8.7.6/8.7.3) id RAA00532; Tue, 14 Jan 1997 17:03:00 -0500 Date: Tue, 14 Jan 1997 17:03:00 -0500 Message-Id: <199701142203.RAA00532@halifax.syncomas.com> From: "Jonathan S. Shapiro" To: wilson@cs.utexas.edu CC: sasos@cs.dartmouth.edu, eros-arch@eros.cis.upenn.edu Subject: Doing a SASOS on EROS In response to one of Paul's comments (which I wanted to correct), I thought I would lay out how one would build a SASOS under EROS, but I thought it appropriate to do it in a separate note. Those of you not interested in EROS (or already know a lot about it) might wish to skip the leading chunk. [Paul writes:] >...in EROS, what you're mapping is segments >in a segmented address space, but in Opal the "segments" are logical >segments of a flat address space. (And that could be generalized to >allow discontiguous "segments", which seems like a good idea.) They're >just there for access policy, not for addressing mechanisms. In EROS, as in all of the SASOS systems I know, what you are ultimately mapping is pages. As in Opal, the pages are parts of a *segmented* address space in which all segments are of equal size and must fall at addresses congruent to that size (i.e. they are pages). Both styles allow "discontinuous" segments. The EROS pages come from a flat address space as well; in EROS it's the single level store. The difference is that EROS allows the applications to define different name spaces for these objects, while a SASOS does not. What follows is a description of how mapping works in EROS, which may not be of interest to everyone. It's here as preamble to a section below outlining how one would build a SASOS environment under EROS. HOW EROS ADDRESS SPACES ARE BUILT EROS's basic objects, as I mentioned before, are data pages (pages) and capability pages (capages). Capability pages hold 16 capabilities. In EROS, the "representation" of the address mapping structure is known to applications. An "address space" looks very like a traditional hierarchical page table. Imagine such a page table whose mapping pages held only 16 page table entries and you have the core of it. The correspondence is as follows: null capability => invalid page table entry (at any level) page capability => valid page table entry w/ read or read-write permissions capage capability => valid page directory entry w/ read or read-Write permissions By "page table entry" I mean an entry that names a page. By "page directory entry" I mean an entry that names a further mapping table (i.e. a subspace). Given this structure, you can map any page you want at any address you please, and translating the mapping onto a particular hardware mechansim is straightforward. Two problems remain: 1. The tree height required to map a 32 bit address space, never mind a 64 bit address space, is excessive. 2. The internal structure of the mapping is exposed to view, which is may be undesirable. The tree height problem is resolved by borrowing a trick from the old 68k MMU (and several before it): each capage capbility encodes the "height" of the tree it describes. If the offset exceeds the size of the subtree, it is deemed invalid. If the subtree is taller than the subtree we would have naturally expected, that is fine - the offset is interpreted as relative to offset 0 in the larger subtree (in effect we use the leading subspace of appropriate size -- this proves very convenient in implementing COW). Encoding the size allows the mapping structure itself to be minimized, and also allows it to be lazily expanded. This reduces both the storage and the runtime overhead of managing it. The visibility problem is dealt with by distinguishing three types of capage capabilities that are acceptable in a memory translation context: capage capabilities -- everything is exposed to the holder segment capabilities -- internal structure is opaque to holder, remains visible to kernel. sense capability -- structure is exposed, but access is guaranteed transitively read-only. The usual practice is to have the top of the address space tree be a segment capability, and populate it internally with capage capabilities. This hides the structure from the user, but not from the segment's fault handler (which we call a keeper). [Unnecessary Detail: The sense capability acts like a RO capage capability, but transitively. Whenever you copy a capability to your capability registers via a sense capbility the copied capability's authority is downgraded so as to ensure transitive sense behaviour. The rules are: [RO] Page cap => RO page cap [RO,NC] segment cap => RO NC segment cap [RO] capage cap => sense cap Number cap => (itself) other => NULL cap. A NOCALL (NC) segment suppresses fault handler invocation and reflection (see below), which prevents the fault handler from being a channel.] The catch with an opaque structure, of course, is that you are now restricted in the alignment of your mapping. In practice, this restriction doesn't appear to be a problem very often, and it is more efficient to match the alignment in any case -- shared mapping tables, among other things. To allow the alignment to be fully determined by the mapping process, there is a fourth type of capability that we allow in a memory context: the window capability. A segment can name a "background segment". A "window capbility" says, in effect: If you wish to traverse the subtree that should have appeared here, go to the following OFFSET in the background segment and traverse there instead. The window capability does not currently encode it's height (it's assumed to be the next level down from it's containing capage's height), but I am lately thinking that it ought to. The maximum address space size in EROS is 2^96 bytes. Unless otherwise arranged (e.g. by means of a window capability), the virtual address mapping seen by a process is the leading 2^32 bytes of the address space. Apologies for the length -- now we get to the interesting part: DOING A SASOS ON EROS An EROS process has no "map" operation. An address space (remember it's recursively defined) can be mapped only if the application has been given a copy of its address space capability in one of its capability registers (usually it has) AND one of the following conditions holds: 1. The address space capability is a capage capability, in which case the application has mutable access to it's own address space structure. 2. The application's address space is named by a segment capability (which allows it to communicate with the space's "keeper", if any), the segment has a keeper, and the segment's keeper is cooperative. To enforce a SASOS discipline in EROS, one would provide to each process in one of its capability registers a segment capability to it's address space, and define a SASOS keeper for that segment at the time the process is constructed. When the application wishes to perform a mapping, it would directly invoke this segment capability. Invocations on a segment capapability whose segment has a keeper are reflected by the kernel to the keeper. The keeper receives the arguments provided by the user plus a capage capability to the capage named by the invoked segment capability (this grants the keeper mutable access to the domain). [DETAIL: the no-call attribute suppresses the reflection of segment capability invocations] The SASOS keeper now locates a suitable range of the (global) address space, makes note of the fact that this range is now occupied by the object in question, maps the object into the caller address space, and returns to the caller. The caller now passes the capability to the original object to some other party, who in turn requests a mapping of the object. The SASOS keeper this time discovers that a suitable region has already been assigned to this object and makes it visible in the new caller. Note that to preserve the confinement arguments the SASOS must be part of the TCB, as it constitutes a shared object. The approach above assumes that the mapping is to be reference counted. If we wished to impose the map/grant model of L4, the necessary book-keeping would be slightly different. (DE)MERITS OF EXPOSURE I can argue the merits of exposing the mapping structures both ways. On the down side, exposure makes them hard to change later, and a tree structure is not always obviously mapped to the hardware (e.g. hash-structured hardware mapping tables -- though we found a nice solution). On the plus side, the exposure makes things like copy-on-write easy to implement with low overhead, and the fact that a program can share mapping substructure explicitly places a surprising amount of control over traditional "aliasing" problems in the hands of the application. For example, an application that wishes to guarantee that it's mapping tables will remain within it's working set can arrange not to share those mapping tables by avoiding shared substructure. >It just seems that the basic approach of using overlapping protection >domains and a flat address space seems applicable to seriously >security-oriented systems. Once you start granting access to memory >segments, you can make it much nicer by providing a flat address >space. Flat is certainly nicer. For some applications, it may be sufficiently compelling that they should all share an address mapping. Providing first-class support for such applications seems like a truly fine idea, and can be provided straightforwardly using the EROS abstractions. Perhaps one should even strongly encourage the use of this model. Requiring that ALL applications use this model seems more problematic to me - I haven't got religion on the SASOS notion. A trivial example: In EROS, an application need not be aware of whether a service is provided by the kernel or by another application. There are (obscure) means to detect which is true, but the invocation protocol is absolutely identical. It is not clear that the kernel should be visible within the application address space at all, and it seems very clear that it's "share" of the address space should be reasonbly bounded. Unfortunately, the set of desirable services in the world is NOT bounded, nor is the mapping requirement of any one service bounded (just look at the size of various MS Word subsystems over the years!). Jonathan From crow@cs.dartmouth.edu Tue Jan 14 17:01:01 1997 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.8.3/4.4) id RAA04311; Tue, 14 Jan 1997 17:00:54 -0500 (EST) Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.6/8.7.3) with ESMTP id QAA12409; Tue, 14 Jan 1997 16:54:59 -0500 Message-Id: <199701142154.QAA12409@eros.cis.upenn.edu> To: G.Heiser@unsw.edu.au cc: sasos@cs.dartmouth.edu, shap@eros.cis.upenn.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "Wed, 15 Jan 1997 08:24:07 +1100." <970114212408.19824@cse.unsw.edu.au> Date: Tue, 14 Jan 1997 16:54:59 -0500 From: "Jonathan S. Shapiro" In message <970114212408.19824@cse.unsw.edu.au>, Gernot Heiser writes: > You'd also have to lock the protection domain, i.e. disallow attaching > further segments. Otherwise the untrusted program could attach a > writable segment, the capability of which it has hidden in its code. Efficiency may demand that the application be able to map other segments into it's protection domain. Locking the entire domain seems a bit strong! The real problem is password capabilities. They prevent you from determining the basis set from which to make the transitive closure argument. Jonathan From crow@cs.dartmouth.edu Tue Jan 14 17:17:36 1997 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.3/4.4) id RAA04536; Tue, 14 Jan 1997 17:17:30 -0500 (EST) Received: From moench.disy.cse.unsw.EDU.AU By huon With Smtp ; Wed, 15 Jan 97 09:16:48 +1100 From: Gernot Heiser To: "Jonathan S. Shapiro" Date: Wed, 15 Jan 1997 09:16:46 +1100 Message-Id: <970114221647.21959@cse.unsw.edu.au> cc: wilson@cs.utexas.edu (Paul R. Wilson), sasos@cs.dartmouth.edu Subject: Re: Capbilities, SASOS, and Confinement In-reply-to: Your message of "Tue, 14 Jan 1997 15:26:22 CDT." <199701142026.PAA12063@eros.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@unsw.edu.au >>>>> "JSS" == Jonathan S Shapiro writes: JSS> One beauty of the pure capability model is the closure property. JSS> Given an initial set of capabilities, one can perform a transitive JSS> closure operation to determine the reachable set of objects. So long JSS> as the set does not include the authority to amplify the initial set, JSS> one can then assert that the set is closed with respect to addition. JSS> This is the crux of the confinement proof. JSS> When names and authorities become separated as in a SASOS, one shortly JSS> becomes tempted to introduce an operation that allows one party to JSS> "publish" access rights to an object. Examples of such operations in JSS> UNIX include JSS> chmod, chgrp, chown, creat, write, open, .... JSS> in a SASOS, one could imagine an option to the map operation JSS> MAP_PUBLIC, which meant "make this mapping visible to anyone". JSS> Such an operation violates the closure argument, which breaks the JSS> confinement and fault containment proof. It remains possible to buid JSS> fault contained systems, but it is now impossible to prove that they JSS> are fault contained. JSS> Provided that Opal (insert your SASOS here) lacks any such operation, JSS> I don't see a problem with the closure argument. There is no need for such an operation. To make an object publicly available, you don't "make this mapping visible to anyone" (i.e. insert a cap into everybody's PD), but rather you publish the capability (via some directory service) and _allow_ everyone to attach the respective segment to their PD. If you provide the possibility of locking a PD you can, IMHO, do the same sort of confinement as EROS can. -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot From crow@cs.dartmouth.edu Tue Jan 14 17:30:42 1997 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.3/4.4) id RAA04667; Tue, 14 Jan 1997 17:30:25 -0500 (EST) Received: From moench.disy.cse.unsw.EDU.AU By huon With Smtp ; Wed, 15 Jan 97 09:29:54 +1100 From: Gernot Heiser To: "Jonathan S. Shapiro" Date: Wed, 15 Jan 1997 09:29:52 +1100 Message-Id: <970114222953.22443@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: 32bit SASOS? In-reply-to: Your message of "Tue, 14 Jan 1997 16:54:59 CDT." <199701142154.QAA12409@eros.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@unsw.edu.au >>>>> "JSS" == Jonathan S Shapiro writes: JSS> In message <970114212408.19824@cse.unsw.edu.au>, Gernot Heiser writes: >> You'd also have to lock the protection domain, i.e. disallow attaching >> further segments. Otherwise the untrusted program could attach a >> writable segment, the capability of which it has hidden in its code. JSS> Efficiency may demand that the application be able to map other JSS> segments into it's protection domain. Locking the entire domain seems JSS> a bit strong! JSS> The real problem is password capabilities. They prevent you from JSS> determining the basis set from which to make the transitive closure JSS> argument. Sorry, I don't quite follow. PW caps are not under system control, ok. But the PD is. What's the difference between a kernel controlled PD (which is essentially the set of caps known to the kernel) which requires some operation to add furhter caps, and a kernel capability list as you have it in segregated schemes? Not much conceptually, I suppose. The differences are mostly on the practical side. PW caps can be passed between processes without kernel intervention (e.g. via share memory). The drawback is you need to lock the PD if you want confinement. But you must have the equivalent in a segregated scheme if you want confinement. BTW, nothing of this is SASOS specific. You don't need to base a SASOS on PW caps. Angel uses a completely different approach. Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot From crow@cs.dartmouth.edu Tue Jan 14 17:37:15 1997 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.8.3/4.4) id RAA04842; Tue, 14 Jan 1997 17:37:09 -0500 (EST) Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.6/8.7.3) with ESMTP id RAA12590; Tue, 14 Jan 1997 17:30:53 -0500 Message-Id: <199701142230.RAA12590@eros.cis.upenn.edu> To: G.Heiser@unsw.edu.au cc: sasos@cs.dartmouth.edu Subject: Re: Capbilities, SASOS, and Confinement In-reply-to: Your message of "Wed, 15 Jan 1997 09:16:46 +1100." <970114221647.21959@cse.unsw.edu.au> Date: Tue, 14 Jan 1997 17:30:53 -0500 From: "Jonathan S. Shapiro" In message <970114221647.21959@cse.unsw.edu.au>, Gernot Heiser writes: > > There is no need for such an operation. To make an object publicly > available, you don't "make this mapping visible to anyone" (i.e. insert > a cap into everybody's PD), but rather you publish the capability (via > some directory service) and _allow_ everyone to attach the respective > segment to their PD. If you provide the possibility of locking a PD you > can, IMHO, do the same sort of confinement as EROS can. I sure hope that directory is part of the TCB! It's a shared channel of arbitrarily large bandwidth. Locking the PD is overly restrictive. A locked PD is certainly frozen, making it amenable to the closure analysis, but requiring that NO mappings be altered for the lifetime of the confined object seems unfortunate. Perhaps more important, there would seem to be no way to do the analysis without a recursive walk of the authority structure at run time. A program that can do this has a frightful amount of authority. If you use partitioned capabilities instead of password capabilities, the proof can be constructed incrementally without such a recursion step using local knowledge at each step. I'm not claiming one is "better" -- some things are definitely simplified by password capabilities. Jonathan From crow@cs.dartmouth.edu Tue Jan 14 18:36:09 1997 Received: from halifax.syncomas.com by cs.dartmouth.edu (8.8.3/4.4) id SAA06099; Tue, 14 Jan 1997 18:35:58 -0500 (EST) Received: (from shap@localhost) by halifax.syncomas.com (8.7.6/8.7.3) id SAA00797; Tue, 14 Jan 1997 18:41:42 -0500 Date: Tue, 14 Jan 1997 18:41:42 -0500 Message-Id: <199701142341.SAA00797@halifax.syncomas.com> From: "Jonathan S. Shapiro" To: G.Heiser@unsw.edu.au Cc: sasos@cs.dartmouth.edu Subject: Passwd v/s Partitioned capabilities > What's the difference between a kernel controlled PD (which is > essentially the set of caps known to the kernel) which requires some > operation to add furhter caps, and a kernel capability list as you > have it in segregated schemes? Not much conceptually, I suppose. Unless you are concerned about making arguments predicated on the capability graph, perhaps there isn't much of a difference. Suppose, however, that you "freeze" the protection domain in the way you propose. Here are some useful operations that the process can no longer be permitted to do if we are going to get this right. Receive an IPC -- an IPC conveys the authority to perform a reply, which cannot be accepted if the protection domain is frozen. Alter the protections of it's memory map. I think you'll quickly conclude that you don't so much want to freeze the protection domain as preclude "amplifying" operations -- a process should be able to discard/reduce authorities. Perform an IPC (i.e. a call) -- the application might be subverting the frozen protection domain by passing some capability to an unfrozen collaborator who will perform the operation on their behalf. Note that properly the collaborator will preclude ANY IPC to it. Perform a store to memory. Unless an exhaustive analysis of the system has been done, it is possible that a program outside the containment boundary holds read access to a memory object mapped by the "frozen" application. The last one would seem to pose a fairly severe restriction, though I suppose one could argue that there are enough registers on a modern processor to get useful work done :-) Okay, perhaps I'm being a bit glib, but the problems I've listed are real. It's the last one that's the gut buster. Let 'M' be a memory object (segment) you would like to ensure is accessable only within the confinement boundary. Examining the *current* state of the system is not good enough. You actually need to know that no third party can *ever* build a readable mapping to M. In a password capability system, this would seem to require scouring every bit in data space. >The differences are mostly on the practical side. PW caps can be passed >between processes without kernel intervention (e.g. via share >memory). Before responding, I agree with your basic point, which is an argument for efficiency. Current processors have regrettable privilege crossing delays in spite of the best that Jochen and I and others can do to minimize them. MIPS does decently well. SPARC can be made to if you work really hard. I suspect the P7 will do well. Conceptually, however, there is no reason not to share a capability address space in addition to a data address space. Imagine the capability load/store instruction to be an emulated instruction on most processors and you're conceptually done. I grant that on a processor with high privilege crossing overhead this implementation would be less than ideal. EROS does not currently support such a shared space with data-space style protections -- we intend to, but have not had time to do the implementation. An alternative made possible by load-time code translation is to partition the data address space into data and capability space, and sandbox the data references at application load time -- in effect implementing the supervisor bit in the code loader. One could then load a trusted (un-sandboxed) library into application space that is entitled to manipulate capability space data, removing the privilege crossing overhead at a roughly 10% overhead in overall execution. Depending on frequency of capability invocation this might be a reasonable implementation. >The drawback is you need to lock the PD if you want confinement. But >you must have the equivalent in a segregated scheme if you want >confinement. It turns out that you don't need the equivalent of PD locking in a segregated scheme. The goal is to get a collection of programs running as a single confined subsystem. Ideally, it should be possible to confine common utility programs (e.g. a database subsystem) without doing a great deal of prior planning. Rules for Confinement: 1. A program instance P0 having no mutable storage or outbound communication channels is confined. 2. A program instance P0 having no outbound communication channels, all of whose MUTABLE storage can be shown to be private to P0 is confined, provided that the client can be shown to have exclusive access to the program. 3. A client of a confined program instance P0 who holds exclusive access to a second confined program instance P1 may give this authority to P0. The aggregate subsystem consisting of {P0, P1} may intercommunicate freely, but is still confined. [If the client gave up exclusive access on P1 by handing it around, that's their lookout] It's fairly easy to construct a (transitively) immutable address space using the capabilities I described in the "SASOS on EROS" note. Either a sense capability or a read-only no-call segment capability will suffice. Imagine that there exists a trusted source of data pages and capability pages. I'll call it a space bank, and you can read about it in the EROS online manual. The crucial property of the space bank is that when it hands you an object you are the exclusive holder of that object and it will not be granted to anyone else by the space bank. The space bank is part of the TCB. Let me wave my hands for a moment about the copy-on-write manager. Assume for the moment that it is confined. It proves unnecessary to place it within the TCB. Given a confined copy-on-write manager, an immutable memory object, and a trusted space bank, it's straightforward to make an efficient virtual copy of the original segment whose mutable state is exclusively held by the program instance [alternatively, one can xerox the initial segment, which is how the problem of the copy on write manager's confinement is handled]. Now all we need is a trusted construction agent. In EROS this is called an escrow. The job of an escrow is to build program instances. An escrow contains a set of capabilities plus a set of construction rules. The construction rules are of the form 'insert this capability X (from the set) into slot Y of your product'. The escrow is able to examine the capabilities within the set to determine if any of them convey mutate authority. The escrow can be *asked* if the set contains such a leak. Now for the tricky part. One of the things in the set of capabilities may be a capability to another escrow (the escrow is able to recognize and authenticate it's siblings, and can therefore trust their certifications in turn). Construction rules may say: insert the product of invoking capability X (in the set), which is an escrow capability, into slot Y of your product. The most common escrow to use in this fasion is probably the escrow that produces copy-on-write address spaces. Second most common are escrows that build services used by the original service. A client wishing to use a confined service goes to the service escrow and says "do you certify that your service is confined, excepting only those capabilities in this here set that I am willing to trust?" Assuming that the escrow will certify, or that the client is willing to take their chances, the client now asks the escrow to produce it's product. It hands in: the space bank instance from which space should be purchased the scheduling reserve that the product should use the working set reserve under which the program should operate [not yet] The escrow constructs the product and starts it, passing it the ability to return to the client. The product is known to be exclusively held by the client and confined by virtue of certification of the escrow agent. Both the closure property and the initial analysis of confinement seem to be necessary to this approach regardless of the details of the implementation. I don't know how one would build the analogous story with password capabilities, because the initial, "frozen" segment may contain password capabilities within it. Note, however, that there is no "freezing" required. Indeed, the service is free to dynamically fabricate subservices as needed in response to client demand, provided that those subservices are confined (which their escrows will certify). Jonathan From crow@cs.dartmouth.edu Tue Jan 14 19:24:10 1997 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.3/4.4) id TAA06908; Tue, 14 Jan 1997 19:24:04 -0500 (EST) Received: From moench.disy.cse.unsw.EDU.AU By huon With Smtp ; Wed, 15 Jan 97 11:23:11 +1100 From: Gernot Heiser To: "Jonathan S. Shapiro" Date: Wed, 15 Jan 1997 11:23:09 +1100 Message-Id: <970115002311.29428@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: Passwd v/s Partitioned capabilities In-reply-to: Your message of "Tue, 14 Jan 1997 18:41:42 CDT." <199701142341.SAA00797@halifax.syncomas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@unsw.edu.au >>>>> "JSS" == Jonathan S Shapiro writes: JSS> Suppose, however, that you "freeze" the protection domain in the way JSS> you propose. Here are some useful operations that the process can no JSS> longer be permitted to do if we are going to get this right. JSS> Receive an IPC -- an IPC conveys the authority to perform a reply, JSS> which cannot be accepted if the protection domain is frozen. Why do you need IPC in a SASOS? Communication is via shared memory. You'll need a synchronisation primitive (e.g. semaphores). Do you need more? In Mungi we're trying to see how far we can go without IPC in the model. JSS> Alter the protections of it's memory map. I think you'll quickly JSS> conclude that you don't so much want to freeze the protection JSS> domain as preclude "amplifying" operations -- a process should JSS> be able to discard/reduce authorities. Sure. JSS> Perform an IPC (i.e. a call) -- the application might be JSS> subverting the frozen protection domain by passing some JSS> capability to an unfrozen collaborator who will perform the JSS> operation on their behalf. Note that properly the collaborator JSS> will preclude ANY IPC to it. See above. In the Mungi context, you need fairly severe restrictions on PDX (protected procedure calls). JSS> Perform a store to memory. Unless an exhaustive analysis of the JSS> system has been done, it is possible that a program outside the JSS> containment boundary holds read access to a memory object mapped JSS> by the "frozen" application. Why? You set the PD up so it only contains write caps to objects you've created and you haven't given read caps away. The process is then free to write to anything writable (which, of course, it needs to to be able to communicate with the creator). Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot From crow@cs.dartmouth.edu Tue Jan 14 21:01:25 1997 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.8.3/4.4) id VAA08558; Tue, 14 Jan 1997 21:01:24 -0500 (EST) Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.6/8.7.3) with ESMTP id UAA13244; Tue, 14 Jan 1997 20:55:29 -0500 Message-Id: <199701150155.UAA13244@eros.cis.upenn.edu> To: G.Heiser@unsw.edu.au cc: sasos@cs.dartmouth.edu, shap@eros.cis.upenn.edu Subject: Re: Passwd v/s Partitioned capabilities In-reply-to: Your message of "Wed, 15 Jan 1997 11:23:09 +1100." <970115002311.29428@cse.unsw.edu.au> Date: Tue, 14 Jan 1997 20:55:29 -0500 From: "Jonathan S. Shapiro" > JSS> Receive an IPC -- an IPC conveys the authority to perform a reply, > JSS> which cannot be accepted if the protection domain is frozen. > > Why do you need IPC in a SASOS?... I was trying to respond to the idea of freezing protection domains without focusing on SASOS's in particular. You may indeed not need such an operation in a SASOS. The only reason I can think of to want one is to provide a mechanism by which to transmit non-memory resources such as open file descriptors. > JSS> Perform a store to memory. Unless an exhaustive analysis of the > JSS> system has been done, it is possible that a program outside the > JSS> containment boundary holds read access to a memory object mapped > JSS> by the "frozen" application. > > Why? You set the PD up so it only contains write caps to objects you've > created and you haven't given read caps away. I addressed this more fully in another piece of mail. Short form: 1. Who is "you" 2. How can you be sure that you are the only source of authority? If you permit the program to run at all before you "freeze" the PD it has an opportunity to activate PW capabilities that may live in it's address space. Jonathan From crow@cs.dartmouth.edu Tue Jan 14 21:08:58 1997 Received: from albeniz.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.3/4.4) id VAA08724; Tue, 14 Jan 1997 21:08:50 -0500 (EST) Received: From moench.disy.cse.unsw.EDU.AU By huon With Smtp ; Wed, 15 Jan 97 13:07:57 +1100 From: Gernot Heiser To: "Jonathan S. Shapiro" Date: Wed, 15 Jan 1997 13:07:52 +1100 Message-Id: <970115020754.4965@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: Passwd v/s Partitioned capabilities In-reply-to: Your message of "Tue, 14 Jan 1997 20:55:29 CDT." <199701150155.UAA13244@eros.cis.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@unsw.edu.au >>>>> "JSS" == Jonathan S Shapiro writes: JSS> Receive an IPC -- an IPC conveys the authority to perform a reply, JSS> which cannot be accepted if the protection domain is frozen. >> >> Why do you need IPC in a SASOS?... JSS> I was trying to respond to the idea of freezing protection domains without JSS> focusing on SASOS's in particular. You may indeed not need such an operation in a JSS> SASOS. The only reason I can think of to want one is to provide a mechanism by JSS> which to transmit non-memory resources such as open file descriptors. What's a "file"? :-) JSS> Perform a store to memory. Unless an exhaustive analysis of the JSS> system has been done, it is possible that a program outside the JSS> containment boundary holds read access to a memory object mapped JSS> by the "frozen" application. >> >> Why? You set the PD up so it only contains write caps to objects you've >> created and you haven't given read caps away. JSS> I addressed this more fully in another piece of mail. Short form: JSS> 1. Who is "you" JSS> 2. How can you be sure that you are the only source of authority? JSS> If you permit the program to run at all before you JSS> "freeze" the PD it has an opportunity to activate PW JSS> capabilities that may live in it's address space. I'd do it roughly like this: 1) make a new PD (in Mungi that means create a new task) 2) the code running in that PD (i.e. mine) tailors the PD to what is needed, or it is set up as needed upon creation, doesn't matter 3) freeze the PD (in Mungi, that would be done by the task itself, still running "my" code) 4) exec the untrusted code (i.e. exchange "my" code for "yours", still remaining in the same PD). Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot From crow@cs.dartmouth.edu Tue Jan 14 22:53:22 1997 Received: from eros.cis.upenn.edu by cs.dartmouth.edu (8.8.3/4.4) id WAA09773; Tue, 14 Jan 1997 22:53:21 -0500 (EST) Received: from eros.cis.upenn.edu (localhost [127.0.0.1]) by eros.cis.upenn.edu (8.7.6/8.7.3) with ESMTP id WAA13614; Tue, 14 Jan 1997 22:47:30 -0500 Message-Id: <199701150347.WAA13614@eros.cis.upenn.edu> To: G.Heiser@unsw.edu.au cc: sasos@cs.dartmouth.edu Subject: Re: Passwd v/s Partitioned capabilities In-reply-to: Your message of "Wed, 15 Jan 1997 13:07:52 +1100." <970115020754.4965@cse.unsw.edu.au> Date: Tue, 14 Jan 1997 22:47:30 -0500 From: "Jonathan S. Shapiro" In message <970115020754.4965@cse.unsw.edu.au>, Gernot Heiser writes: > What's a "file"? :-) file: n. A receptacle that keeps loose objects, esp. papers, in useful order. [< ME filen, to put documents on a thread < OFr. filer < Lat. filum, thread.] file: tr.v. To sully; defile. [ME filien < OE fylen] -- direct from the dictionary, I bleat you not. The dictionary indicates that the second definition is obsolete. I'm not so sure :-) > I'd do it roughly like this: > > 2) the code running in that PD (i.e. mine) tailors the PD to what is > needed, or it is set up as needed upon creation, doesn't matter Presumably this program is trusted. Okay so far. > 3) freeze the PD (in Mungi, that would be done by the task itself, > still running "my" code) The frozen PD now has a capability for a memory region that contains trusted code which will be inherited by the new code. Handle with care. > 4) exec the untrusted code (i.e. exchange "my" code for "yours", still > remaining in the same PD). Changing the address space (bearing in mind that the target program may need to run with lesser address space than the setup agent) is an authority change. You shouldn't be able to do an authority change on a frozen PD. One solution is to reify a capability for a PD and have a builder populate the PD for hte untrusted program. Setting this aside, there remains a problem inherent in the notion of a frozen PD. Confinement is not a full-duplex contract. It guarantees that the protected subsystem will not contain leaks at startup time, but in order to be useful it is often necessary that the PD be able to accept new channels from its client. E.g. the client should be able to hand a mutable memory region to the service PD that the PD can activate. I'ld propose something slightly different from your freeze operation. It should be legal for a program to attempt to "activate" any capability that is already activated in the PD. Equally, it should be legal for a program to activate any capability whose authority is a subset of some existing capability -- e.g. a RO mapping capability. It's perfectly safe to allow PD's to transfer capabilities that are already activated -- the activated subset is, in effect, a partitioned capability space. The problem is that you now need a supervisor operation by which to transfer these activated capabilities. There are a variety of ways to do this. In EROS, the mechanism is to invoke a "start capability" to the recipient PD, which is what I have referred to as IPC. At this point, however, I'm not so convinced that having the capabilities *outside* the PD is buying you all that much. Still, I begin to see the shape of how you have in mind to solve this, and I very much appreciate your taking the time to explain it to someone as dense as I can be. Jonathan From crow@cs.dartmouth.edu Wed Jan 15 18:14:22 1997 Received: from dartvax.dartmouth.edu by cs.dartmouth.edu (8.8.3/4.4) id SAA28538; Wed, 15 Jan 1997 18:14:22 -0500 (EST) Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.8.4+DND/8.8.4) with SMTP id SAA11507 for ; Wed, 15 Jan 1997 18:14:21 -0500 (EST) Message-id: <37875855@dancer.Dartmouth.EDU> Date: 15 Jan 97 18:13:27 EST From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: SASOS list admin To: sasos@cs.dartmouth.edu As the administrator for the SASOS list, I would like to take a moment to remind everyone of a few details about this list. First, any updates to the list (subscriptions and such) should be sent to me at: sasos-request@cs.dartmouth.edu For now, I'm doing it manually, so there's no need to follow a specific format. Second, there is a set of web pages for this list: http://www.cs.dartmouth.edu/cs_archive/sasos/sasos.html You'll find a list archive there, as well as a bibliography and a list of relavant projects. --PC From crow@cs.dartmouth.edu Thu Jan 16 02:15:03 1997 Received: from server-a.cs.interbusiness.it by cs.dartmouth.edu (8.8.3/4.4) id CAA02027; Thu, 16 Jan 1997 02:15:01 -0500 (EST) Received: from edposv.rub065.ao00.pv.interbusiness.it (rub065.ao00.pv.interbusiness.it [195.120.160.65]) by server-a.cs.interbusiness.it (8.7.5/8.7.3) with SMTP id IAA19167 for ; Thu, 16 Jan 1997 08:14:51 +0100 (MET) Message-ID: <32DE54CA.1170@interbusiness.it> Date: Thu, 16 Jan 1997 08:18:18 -0800 From: "Tecdis S.p.A." Organization: TECDIS S.p.A. X-Mailer: Mozilla 2.01 (Win16; I) MIME-Version: 1.0 To: sasos@cs.dartmouth.edu Subject: rmove from mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could you please remove my name from your mailing list thank in advance regards From crow@cs.dartmouth.edu Sat Apr 19 17:33:46 1997 Received: from jtb by cs.dartmouth.edu (8.8.3/4.4) id RAA00922; Sat, 19 Apr 1997 17:33:44 -0400 (EDT) Received: from dial139.brunet.bn by jtb; (5.65v3.2/1.1.8.2/03Oct95-0602PM) id AA09535; Sun, 20 Apr 1997 05:37:42 +0800 Message-Id: <2.2.32.19970419213350.006771c0@brunet.bn> X-Sender: jainahhr@brunet.bn X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Apr 1997 05:33:50 +0800 To: sasos@cs.dartmouth.edu From: Jainah Hj Rabaha Dear Sir/ Madam, I am a student of a local college in Brunei. I would like to ask you some questions about the Operating System coz' I don't quite really understand the OS in your Home Page, Here goes... 1. What are the program / utilities that are included in OS package? and their funtions. 2. What are the Operating Systems for the following platform: i - Supercomputers ii- Mainframe iii- Minicomputers iv - LAN servers v - Desktops and their functions too.. Please answer me immediately, I really need your help... I don't quite understand this OS problems, our lecturer asked us to reasearch... but in our library... the books are not quite up-to-date, so again, please... help me! sincerely, **************************************************************************** ******** Inah ND CST 08 Maktab Teknik Sultan Saiful Rijal Jln Muara Brunei Darussalam **************************************************************************** ******** From crow@cs.dartmouth.edu Tue Apr 22 04:16:05 1997 Received: from mail.virginia.edu by cs.dartmouth.edu (8.8.3/4.4) id EAA08856; Tue, 22 Apr 1997 04:16:05 -0400 (EDT) Received: from archive.cs.virginia.edu by mail.virginia.edu id aa26233; 22 Apr 97 4:15 EDT Received: from cs.virginia.edu (adder-fo.cs.Virginia.EDU [128.143.136.11]) by archive.cs.Virginia.EDU (8.7.5/8.7.3) with ESMTP id EAA24115; Tue, 22 Apr 1997 04:15:46 -0400 (EDT) Message-Id: <199704220815.EAA24115@archive.cs.Virginia.EDU> Reply-to: chapin@cs.virginia.edu To: achien@cs.uiuc.edu, amnon@cs.huji.ac.il, andy@comp.vuw.ac.nz, assaf@cs.technion.ac.il, bershad@cs.washington.edu, calton@cs.ogi.edu, culler@cs.berkeley.edu, darrell@cse.ucsc.edu, dejan@osf.org, dlb@osf.org, donald.miller@asu.edu, douglis@research.att.com, eugen@research.nj.nec.com, feit@cs.huji.ac.il, griff@dcs.uky.edu, hensgen@cs.nps.navy.mil, hj@ecn.purdue.edu, jon@first.gmd.de, jst@cs.wustl.edu, kaashoek@lcs.mit.edu, keleher@cs.umd.edu, kkavi@cse.uta.edu, lepreau@cs.utah.edu, lewis@cs.nps.navy.mil, li@cs.princeton.edu, llp@cs.arizona.edu, mootaz@cs.cmu.edu, norm@cs.ubc.ca, partha.dasgupta@asu.edu, pjh@cs.unh.edu, raj@dcs.uky.edu, reiher@cs.ucla.edu, retrac@cs.utah.edu, roy@cs.uiuc.edu, sasos@cs.dartmouth.edu, scott@cs.rochester.edu, shirazi@cse.uta.edu, stumm@eecg.toronto.edu, vss@mathcs.emory.edu, vsta@cisco.com, willy@cs.rice.edu, wosch@first.gmd.de From: Steve Chapin Zevon-of-the-day: Excitable Boy Subject: CFP: SP&E Special issue on Parallel/Distributed OS Date: Tue, 22 Apr 1997 04:15:34 -0400 Sender: chapin@cs.virginia.edu Call For Articles Software---Practice & Experience Special Issue: Parallel and Distributed Operating Systems We are seeking articles for a special issue of Software---Practice & Experience on Parallel and Distributed Operating Systems. The issue will combine recent research results in the area with lessons learned from mature systems. We are interested in papers in all areas of multiprocessor systems, especially the following: o heterogeneous multiprocessor operating systems: program representation for multiple architectures, and architecture-independent operating system services; o low-overhead protocols for high-speed networks: lightweight remote procedure call, and active messages; o parallel operating systems in general: support for repartitionable parallel architectures, parallel operating system structure, message-passing operating systems, and locking mechanisms; o distributed operating systems in general: microkernel organization, OS structuring, and threading models; o distributed shared memory: coherency mechanisms, scalable approaches to DSM, and single address space operating systems; and o scheduling in multiprocessor systems: local and global scheduling, dynamic and static scheduling, and scheduling for meta-systems. Submissions can range from short research notes of a few pages to full treatments of substantial systems. We welcome descriptions of complete systems, works-in-progress, overviews of current research trends, and visions of future directions. Articles should be written in a lively, tutorial style. SP&E focuses on practical aspects of computing. Typical topics include software design and implementation, case studies, studies describing the evolution of software systems, critical appraisals of systems, and the practical aspects of software engineering. Theoretical discussions can be included, but should illuminate the practical aspects of the work, or indicate directions that might lead to better practical systems. Please submit PostScript via e-mail or, alternatively, submit eight copies to Steve Chapin no later than 27 June 1997. Steve J. Chapin Arthur B. Maccabe Dept. of Computer Science Department of Computer Science Thornton Hall University of New Mexico University of Virginia Albuquerque, NM 87131-1386 Charlottesville, VA 22903 chapin@cs.virginia.edu maccabe@cs.unm.edu From crow@cs.dartmouth.edu Tue Sep 15 21:31:53 1998 Received: from rplace by cs.dartmouth.edu (8.8.8/4.4) id VAA13987; Tue, 15 Sep 1998 21:31:52 -0400 (EDT) Received: (from rob@localhost) by rplace (8.8.6/8.8.4) id VAA00209 for sasos@cs.dartmouth.edu; Tue, 15 Sep 1998 21:22:24 GMT Date: Tue, 15 Sep 1998 21:22:24 GMT From: Rob Place Message-Id: <199809152122.VAA00209@rplace> To: sasos@cs.dartmouth.edu Subject: SASOSes dead? I can't imagine that everybody has given up on SASOSes, but I can't seem to find anything on the web indicating much ongoing activity. So, is there anything going on? Is anybody thinking of any new projects? I would like nothing better than to find something early enough in its life cycle that I could contribute to it. I will be starting grad school (somewhere) in the fall of '99 and have been looking around a lot for interesting OS projects. Rob From crow@cs.dartmouth.edu Wed Sep 16 07:24:40 1998 Received: from note.orchestra.cse.unsw.EDU.AU by cs.dartmouth.edu (8.8.8/4.4) id HAA18226; Wed, 16 Sep 1998 07:24:37 -0400 (EDT) Received: From zuse.disy.cse.unsw.EDU.AU By note With Smtp ; Wed, 16 Sep 98 21:24:31 +1000 From: Gernot Heiser To: sasos@cs.dartmouth.edu Date: Wed, 16 Sep 1998 21:24:27 +1000 Message-Id: <980916112428.9059@cse.unsw.edu.au> Subject: Re: SASOSes dead? In-reply-to: Your message of "Tue, 15 Sep 1998 21:22:24 GMT." <199809152122.VAA00209@rplace> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: G.Heiser@unsw.edu.au I don't think so. At least Mungi is alive and well. An overview paper was just published in Software: Practice and Experience (25 July 1998) and the souce code is about to be released. Details can be found at http://www.cse.unsw.EDU.AU/~disy/Current.html. Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint = 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F From crow@cs.dartmouth.edu Wed Sep 16 07:33:15 1998 Received: from ns.persimmon.com by cs.dartmouth.edu (8.8.8/4.4) id HAA16808; Wed, 16 Sep 1998 07:33:15 -0400 (EDT) Received: by ns.persimmon.com (Smail3.1.29.0 #10) id m0zJFph-0004nmC; Wed, 16 Sep 98 07:33 EDT Message-Id: To: G.Heiser@unsw.edu.au cc: sasos@cs.dartmouth.edu Subject: Re: SASOSes dead? In-reply-to: Your message of "Wed, 16 Sep 98 21:24:27 +1000." <980916112428.9059@cse.unsw.edu.au> Date: Wed, 16 Sep 98 07:33:12 -0400 From: Timothy Roscoe X-Mts: smtp Indeed - work also continues on Nemesis as well. There were a couple of papers about it in NOSSDAV'98. I believe there is a release planned of this as well. -- Timothy Roscoe From crow@cs.dartmouth.edu Wed Sep 16 12:50:53 1998 Received: from post5.inre.asu.edu by cs.dartmouth.edu (8.8.8/4.4) id MAA23317; Wed, 16 Sep 1998 12:50:21 -0400 (EDT) Received: from smtp1.asu.edu by asu.edu (PMDF V5.1-10 #24133) with ESMTP id <01J1VBX17OIG99YBRN@asu.edu> for sasos@cs.dartmouth.edu; Wed, 16 Sep 1998 09:49:35 MST Received: from asu.edu (enws671.eas.asu.edu [149.169.28.107]) by smtp1.asu.edu (8.8.7/8.8.7) with ESMTP id JAA25743; Wed, 16 Sep 1998 09:49:33 -0700 (MST) Date: Wed, 16 Sep 1998 09:49:33 -0700 From: "Donald S. Miller" Subject: SASOSs dead To: sasos@cs.dartmouth.edu, rplace@orn.net, alan skousen Message-id: <35FFEC1D.259266C6@asu.edu> MIME-version: 1.0 X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Rob We are also actively working on and prototyping Sombrero. An overview paper will be presented and appear in Proceedings of IASTED PDCS next month and a paper which has a lot of general material but also emphasizes some of the distributed systems aspects in HICSS-32 Proceedings (mini track on cluster computing) in January 99. A one page thing on the prototype effort was in the USENIX NT Symposium Proceedings last month. Our home page is "under (re)-construction". I will e-mail the SASOS group when I've gotten pointers to a reasonable number of our documents set up. I was in Australia last summer and what Gernot says is definitely true - the Mungi group is both large and active. don miller -- Donald S. Miller Associate Professor Computer Science and Engineering Department Arizona State University Tempe, AZ 85287-5406 email: donald.miller@asu.edu http://www.eas.asu.edu/~sasos phone: (602)-965-5935 Fax: 602/965-2751 From crow@cs.dartmouth.edu Wed Sep 30 13:29:44 1998 Received: from wrath.cs.utah.edu by cs.dartmouth.edu (8.8.8/4.4) id NAA26531; Wed, 30 Sep 1998 13:29:44 -0400 (EDT) Received: from envy.cs.utah.edu (envy.cs.utah.edu [155.99.198.102]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id LAA10963; Wed, 30 Sep 1998 11:28:55 -0600 (MDT) Received: from vorpal (slip50.cs.utah.edu [155.99.200.50]) by envy.cs.utah.edu (8.8.8/8.8.8) with SMTP id LAA02307; Wed, 30 Sep 1998 11:27:59 -0600 (MDT) Message-ID: <001901bdec97$12dafc00$32c8639b@vorpal.cs.utah.edu> From: "John Carter" To: Subject: PPoPP 1999 call for papers Date: Wed, 30 Sep 1998 11:23:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Hi, This is a reminder that the deadline for submitting papers to PPoPP '99 is about a month away now. If you have interesting results related to the principles or practice of parallel programming, please consider submitting a paper. I expect that as in past PPoPPs, the program will be strong, but that obviously depends on the quality of the submissions. Please refer to the URL below if you have any questions regarding PPoPP or our submission policies. Thanks and I hope to see you in a few months at the mega-meeting in Atlanta (FCRC). Cheers, John ========================================================= PPoPP '99 CALL FOR PAPERS SEVENTH ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming in conjunction with the ACM Federated Computing Research Conference Atlanta, Georgia, May 1998 The goal of the PPoPP Symposia is to provide a forum for papers on the principles and foundations of parallel programming, tools and techniques for parallel programming, and experiences in using parallel programming to solve applications problems. Topics of interest include (but are not limited to): * design and implementation of parallel programming languages and systems (including object-oriented languages such as Java); * experiences in using parallel programming to solve applications problems; * programming experience with parallel programming languages and systems; * restructuring compilers and program manipulation systems for parallel systems; * runtime systems issues for parallel systems; * environments, debuggers, monitoring tools and operating system support for parallel programming; * the relationship between parallel programming languages, compilers and machine architecture; and * performance aspects of parallel programming systems. Note that parallel should be construed broadly to include high performance distributed computing (i.e. grids and metacomputing). Papers should report on original research in any of these areas of parallel programming, and should contain enough background material to make them accessible to the entire parallel programming research community. This year, we are particularly soliciting papers that describe experiences in using parallel programming for specific applications problems. For PPoPP, such papers should describe experiences of broad relevance that highlight and document the practical applicability of principles, and the strengths and weaknesses of tools, and platforms. For example, a paper that simply gave a high-level description of a parallel implementation of a structural mechanics application would not be appropriate for this conference. On the other hand, if this experience highlighted some weakness in the compiler or runtime system of the parallel platform, a paper describing this experience and drawing relevant conclusions would be appropriate for PPoPP. In general, papers reporting on experience should indicate how the experiments illustrate general principles; papers oriented towards foundations should indicate how the work illuminates or influences practice. Submission Procedure Electronic submission submission is strongly encouraged. Electronic submissions will be accepted until Thursday October 29, 1998 . See the conference web page at http://www-csag.ucsd.edu/ppopp99/ for electronic submission instructions. Authors who are unable to submit electronically should submit 16 copies of their extended abstract to the program committee chair, shipped to arrive by the submission deadline indicated above. All submissions should be 10 pages maximum, excluding bibliography and figures, typed double spaced or typeset 10-point on 16-point spacing. Submissions should include a return mailing address and if possible an electronic mail address. Authors will be notified of acceptance or rejection by January 15, 1999 . Final versions of accepted papers must be received in camera-ready form by February 15, 1999 . Authors of accepted papers will be expected to sign a copyright release form. Proceedings will be distributed at the conference and possibly as a special issue of SIGPLAN Notices; they will subsequently be available from ACM. Papers published in proceedings are eligible for subsequent publication in refereed ACM journals at the discretion of the editor of the particular journal. Papers describing essentially the same work must not have been published elsewhere or be simultaneously under consideration for publication elsewhere. Online Conference Information This Call for Papers and additional information about the conference can be obtained at the following URL: http://www-csag.ucsd.edu/ppopp/ Program Chair Andrew Chien University of California, San Diego Department of Computer Science and Engineering 9500 Gilman Drive, Dept 0114 La Jolla, CA 92093-0114 U.S.A. voice: (619)822-2458 fax: (619)822-2459 achien@cs.ucsd.edu General Chair Marc Snir IBM T. J. Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598 U.S.A. snir@us.ibm.com Publicity Chair Vijay Karamcheti New York University Department of Computer Science 715 Broadway, Room 704 New York, NY 10003 U.S.A. vijayk@cs.nyu.edu Program Committee * John Carter, University of Utah * Andrew Chien (chair), University of California, San Diego * Jack Dongarra, Oak Ridge National Laboratory * Sandhya Dwarkadas, University of Rochester * Ian Foster, Argonne National Laboratory * Mary Hall, USC Information Sciences Institute * Anthony Hey, Southampton University * James Larus, Microsoft Research * Calvin Lin, University of Texas at Austin * Rusty Lusk, Argonne National Laboratory * Satoshi Matsuoka, Tokyo Institute of Technology * Barton Miller, University of Wisconsin at Madison * Keshav Pingali, Cornell University * J. P. Singh, Princeton University * Chau-wen Tseng, University of Maryland at College Park From crow@cs.dartmouth.edu Tue Oct 6 11:29:13 1998 Received: from wrath.cs.utah.edu by cs.dartmouth.edu (8.8.8/4.4) id LAA29096; Tue, 6 Oct 1998 11:29:12 -0400 (EDT) Received: from envy.cs.utah.edu (envy.cs.utah.edu [155.99.198.102]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id JAA12031; Tue, 6 Oct 1998 09:28:06 -0600 (MDT) Received: from vorpal (slip50.cs.utah.edu [155.99.200.50]) by envy.cs.utah.edu (8.8.8/8.8.8) with SMTP id JAA05289; Tue, 6 Oct 1998 09:26:53 -0600 (MDT) Message-ID: <000601bdf13d$26f60b80$32c8639b@vorpal.cs.utah.edu> From: "John Carter" To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Cc: Subject: Call for papers -- PODC '99 Date: Tue, 6 Oct 1998 09:21:47 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Hi, Submissions for PODC '99 (the 18th Annual ACM SIGACT-SIGOPS Symposium on the Principles of Distributed Computing) are due soon -- NOVEMBER 3RD. As seems to be the case every year, the program committee is especially interested in soliciting more papers describing concrete examples of the use of distributed computing principles (i.e., implementation papers in addition to the more formal papers most often submitted to PODC). Of particular interest to the committe are papers related to mobile computing and the Internet. PODC is one of the few high quality venues available for publishing papers related to distributed systems, so if you have interesting results to report on such a system, please consider submitting a paper describing them. I'll do my part to ensure that high quality applied papers get accepted so that the conference has a balance of foci. Details on the conference, which is a part of the Federated Computing Research Conference (FCRC) in Atlanta next spring, can be found at http://www.cs.tamu.edu/people/hlee/podc.html . If you have any questions regarding the appropriateness of a submission you have in mind, please do not hesitate to contact me or another member of the program committee. Cheers, John Carter (University of Utah) From crow@cs.dartmouth.edu Mon Apr 26 14:56:43 1999 Received: from mail.trouble.net (postfix@night.trouble.net [212.37.0.80]) by cs.dartmouth.edu (8.9.3/8.9.3) with ESMTP id OAA20201 for ; Mon, 26 Apr 1999 14:56:42 -0400 (EDT) Received: by mail.trouble.net (Postfix, from userid 550) id CDFEEC6C6; Mon, 26 Apr 1999 20:56:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.trouble.net (Postfix) with SMTP id A9C7CC6C5 for ; Mon, 26 Apr 1999 20:56:23 +0200 (CEST) Date: Mon, 26 Apr 1999 20:56:23 +0200 (CEST) From: Johan Rydberg To: sasos@cs.dartmouth.edu Subject: How to link code with a SAOS! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! How do a create code that can be used in a SASOS? Should the code be generated with the -fPIC option with GCC? --johan From crow@cs.dartmouth.edu Mon Apr 26 18:08:15 1999 Received: from note.orchestra.cse.unsw.EDU.AU (root@note.orchestra.cse.unsw.EDU.AU [129.94.242.29]) by cs.dartmouth.edu (8.9.3/8.9.3) with SMTP id SAA25245 for ; Mon, 26 Apr 1999 18:08:11 -0400 (EDT) Received: From zuse.disy.cse.unsw.EDU.AU By note With Smtp ; Tue, 27 Apr 99 08:07:36 +1000 From: Gernot Heiser Sender: gernot@zuse.disy.cse.unsw.EDU.AU To: Johan Rydberg Date: Tue, 27 Apr 1999 08:07:31 +1000 Message-Id: <990426220731.31629@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: How to link code with a SAOS! In-reply-to: Your message of "Mon, 26 Apr 1999 20:56:23 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: "Gernot Heiser" >>>>> "JR" == Johan Rydberg writes: JR> Hi! JR> How do a create code that can be used in a SASOS? Should JR> the code be generated with the -fPIC option with GCC? Short answer is that position-independent code is not needed in a SASOS. There will be a paper on linking in a SASOS in Usenix in June. We'll have it on our web page (http://www.cse.unsw.edu.au/~disy/Mungi.html) within the next two days. Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F From crow@cs.dartmouth.edu Tue Apr 27 07:09:04 1999 Received: from vanuata (vanuata.dcs.gla.ac.uk [130.209.240.50]) by cs.dartmouth.edu (8.9.3/8.9.3) with SMTP id HAA00104 for ; Tue, 27 Apr 1999 07:09:02 -0400 (EDT) Received: from bathurst by vanuata with SMTP DCS (MMTA); Tue, 27 Apr 1999 11:21:47 +0100 Received: from localhost by bathurst; (5.65v3.2/1.1.8.2/19Apr96-0202PM) id AA12164; Tue, 27 Apr 1999 11:21:41 +0100 Message-Id: <9904271021.AA12164@bathurst> X-Mailer: exmh version 2.0.2 2/24/98 To: Johan Rydberg Cc: sasos@cs.dartmouth.edu, rjb@dcs.gla.ac.uk Subject: Re: How to link code with a SAOS! In-Reply-To: Your message of "Mon, 26 Apr 99 20:56:23 +0200." Date: Tue, 27 Apr 99 11:21:41 +0100 From: Richard Black X-Mts: smtp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > > Hi! > > How do a create code that can be used in a SASOS? Should > the code be generated with the -fPIC option with GCC? > Not necessarily, it depends on your operating system's general approach to linkage. You may find some interesting papers about how this was handled in the Nemesis SASOS at their web page: http://www.cl.cam.ac.uk/Research/SRG/netos/nemesis/documentation.html Richard. From crow@cs.dartmouth.edu Tue Apr 27 22:43:48 1999 Received: from note.orchestra.cse.unsw.EDU.AU (root@note.orchestra.cse.unsw.EDU.AU [129.94.242.29]) by cs.dartmouth.edu (8.9.3/8.9.3) with SMTP id WAA21468 for ; Tue, 27 Apr 1999 22:43:41 -0400 (EDT) Received: From zuse.disy.cse.unsw.EDU.AU By note With Smtp ; Wed, 28 Apr 99 12:41:34 +1000 From: Gernot Heiser Sender: gernot@zuse.disy.cse.unsw.EDU.AU To: Johan Rydberg Date: Wed, 28 Apr 1999 12:41:05 +1000 Message-Id: <990428024106.5120@cse.unsw.edu.au> cc: sasos@cs.dartmouth.edu Subject: Re: How to link code with a SAOS! In-reply-to: Your message of "Tue, 27 Apr 1999 11:21:41 +0100." <9904271021.AA12164@bathurst> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Reply-to: "Gernot Heiser" The promised USENIX paper on SASOS linking is now available from http://www.cse.unsw.edu.au/~disy/papers/ Gernot -- Gernot Heiser ,--_|\ School of Computer Sci. & Engin. Phone: +61 2 9385 5156 / \ The University of NSW Fax: +61 2 9385 5995 \_,--._* Sydney, Australia 2052 E-mail: G.Heiser@unsw.edu.au v http://www.cse.unsw.edu.au/~gernot PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F From crow@cs.dartmouth.edu Wed Apr 28 02:14:14 1999 Received: from exchsrv1.cs.washington.edu (exchsrv1.cs.washington.edu [128.95.3.128]) by cs.dartmouth.edu (8.9.3/8.9.3) with ESMTP id CAA23685 for ; Wed, 28 Apr 1999 02:14:14 -0400 (EDT) Received: by exchsrv1.cs.washington.edu with Internet Mail Service (5.5.2448.0) id <2YN0PK6H>; Tue, 27 Apr 1999 23:14:14 -0700 Message-ID: <055A195871E5D1119F8100A0C9499B5FAB3E2E@exchsrv1.cs.washington.edu> From: Hank Levy To: "'Johan Rydberg'" , sasos@cs.dartmouth.edu Subject: RE: How to link code with a SAOS! Date: Tue, 27 Apr 1999 23:14:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" In addition to the other pointers, there is a chapter in Jeff Chase's PhD thesis on Opal dealing with linking in a single-address-space OS. You can find it through the opal home page: http://www.cs.washington.edu/homes/levy/opal/opal.html hank -----Original Message----- From: Johan Rydberg [mailto:jrydberg@night.trouble.net] Sent: Monday, April 26, 1999 11:56 AM To: sasos@cs.dartmouth.edu Subject: How to link code with a SAOS! Hi! How do a create code that can be used in a SASOS? Should the code be generated with the -fPIC option with GCC? --johan From crow@cs.dartmouth.edu Wed Jun 2 01:14:33 1999 Received: from asuvax.eas.asu.edu (asuvax.eas.asu.edu [129.219.30.6]) by cs.dartmouth.edu (8.9.3/8.9.3) with SMTP id BAA06717 for ; Wed, 2 Jun 1999 01:14:32 -0400 (EDT) Received: from asu.edu (cx425349-a.chnd1.az.home.com) by asuvax.eas.asu.edu with SMTP id AA20366 (5.65c/IDA-1.4.4 for sasos@cs.dartmouth.edu); Tue, 1 Jun 1999 22:12:52 -0700 Message-Id: <3754BD34.11867D9D@asu.edu> Date: Tue, 01 Jun 1999 22:12:20 -0700 From: dmiller Reply-To: donald.miller@asu.edu Organization: asu X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: sasos@cs.dartmouth.edu Subject: updated Sombrero web pages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit SASOS people The Sombrero web page has finally been updated. it's at the same place http://www.eas.asu.edu/~sasos Included are our published papers, other documents and a number of presentations. Also there is a readme that can help in wading through the stuff. I will do a minor update of the page again this month and a major one in September that will cover some of the things we are working on now: distributed consistency management distributed scheduling software complexity under a SASOS and results from the Sombrero prototype sorry for the low frequency of updates don miller -- Donald S. Miller Associate Professor Computer Science and Engineering Department Arizona State University Tempe, AZ 85287-5406 email: donald.miller@asu.edu http://www.eas.asu.edu/~sasos phone: (480)-965-5935 Fax: 480/965-2751