From gernot@vast.unsw.edu.au Wed Apr 27 15:20:32 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 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".