At Wed, 12 Oct 2005 14:10:34 -0400, Jonathan S. Shapiro wrote: > 2. A capability *names* precisely one interface, by > definition. This interface *may* (but need not) include > operations that return other capabilities. These other > capabilities may or may not name the same representation > state as the original capability. > > Examples: > > The Void capability does not have any methods that > return capabilities. > > The EROS read-write page capability has an operation > that returns a read-only capability to the same page. > > An EROS space bank capability has an operation that > returns page capabilities. These capabilities > do not name the space bank.
I think I understand your examples but I am not convinced that: we can statically determine what interface a capability names based strictly on the RPC name; nor that a capability necessarily names precisely one interface. In the Hurd, most objects are made accessible via the virtual file system. When a task wants to create a pipe, for instance, the standard Hurdish idiom is to ask the pflocal server. To find the pflocal server, a task obtains a capability to `/servers/socket' (which presumably names the fs, i.e. directory, interface). The task invokes that interface using the dir_open method with the string argument "1". (Why 1? That is the number associated with PF_LOCAL.) The returned capability presumably names the socket (server) interface. The reason that we know this is not because dir_lookup necessarily returns capabilities which name the socket interface but because by convention, the node /server/socket/1 names an object which can create sockets. Using the capability, I can invoke the socket_create method. The pfinet server will typically return a capability which names the socket (client) interface AND the io interface. Using the socket (client) interface, a task, for example, can connect two sockets to create a socket pair. Using the io interface, a task can read from and write to a socket. How would capidl express these two usage modes? Would you recommend a different model? Thanks, Neal _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
