[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
capability types
From: |
Neal H. Walfield |
Subject: |
capability types |
Date: |
Sat, 15 Oct 2005 20:21:30 +0100 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
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