Recent development in naming in distributed systems makes it clear that names should transcend machine boundaries, and that files are not the only thing that we want to name. Sprite introduces a machineindependent naming scheme, but only for files Windows NT introduces a heirarchical structure that includes many kinds of “objects”, but they are limited to being of classes predefined by the NT “micro”-kernel, and names are only meaningful on a given machine.

The operating system of the future will have a namespace organized in a heirarchy. Like Sprite, a fully-qualified name will have a meaning independent of the machine interpreting the name. However, names will be allowed to contain enviornment variable references whose meaning is host- (in fact process-) specific (such names are not fully-qualified; performing the variable substitution results in a fully-qualified name). This way it is possible to deal with things such as different binary types, multiple sources of system software, or the desire to store a temporary file on a local disk. For example, the object name

/edu/mit/athena/local/$localhost/fs/tmp/foo would name a temporary file on the current host, and
the object name /edu/mit/lcs/system/$cluster/$hosttype/bin/ls might name the ls program. I

could access a file stored locally on a nearby host with the pathname /edu/mit/athena/local/w20-575-

13/fs/tmp/bar.

Administration of a global namespace would be accomplished as follows. The first several levels of the heirarchy indicate the name of the administrative domain in which the object exists; objects must live in exactly one administrative domain. The objects at this high level are container objects; their only purpose is to contain other objects, and the only operations that most users perform on them are list and search. These top-level objects are read-only, and can thus be highly replicated and cheaply cached. This mechanism distributes the task of administration in the same way that the Internet host namespace does.

The fundamental operations performed on a name are substitute and resolve. Substitute, as mentioned above, turns a name with variable references into a fully-qualified name. Resolve converts a name into an object identifier. This identifier is enough information for the process with the name to call methods of the object. A name-resolution server will run on each node for this purpose, much in the way a named process runs on every host using Internet name service. The name-resolution server keeps track of where objects are located, and also keeps track of which objects exist on the current machine. However, it is the responsibility of a container object to be able to locate its children. Specifically, if a container object receives a search request for a name it contains, it must be able to provide that name’s object identifier.

For example, consider a distributed file system. The object /edu/mit/athena is a replicated, read-only container object with an entry home, which is itself a replicated read-only object with an entry for each username. Each workstation at MIT is permanently configured with the locations of the /edu/mit/athena object (this is how Internet DNS works). Now say I access a file in my home directory, /edu/mit/athena/user/kkkken/sounds/burp. This is the first file access I make on this workstation, so its local name-resolution server asks one of the /edu/mit/athena replicants where to find home; an object identifier is returned. It then asks this object for kkkken, and so on down the chain, much like NFS.

Things other than files can be stored in this system. For example, to kill a process on my machine, I

could call the kill method on /edu/mit/athena/local/m16-034-11/proc/kkkken/134, perhaps. Of course,

variables could be set up so I would merely need to type $domain/local/$host/proc/$user/134 or even $myprocs/134. One nice thing about the system is that if I accidentally left a process running on another machine, I could easly find it and kill it without remotely logging in. I would expect all user-visible operating system data structures to be accessible via object names, including machine performance statistics, access to local daemons, and objects such as semaphores, message queues, and named pipes.

Issues I haven’t addressed are access control and caching of read/write objects. Kerberos works pretty well for access control; objects can maintain access control lists and use kerberos to establish the identities of principals making RPC requests. Maybe the Sprite system works well for caching, I don’t really know.