[cap-talk] A Taxonomy of Current Object-Cap Systems
toby.murray at comlab.ox.ac.uk
Thu Mar 5 04:51:55 EST 2009
On Thu, 2009-03-05 at 00:06 +0000, Mark Seaborn wrote:
> Toby Murray <toby.murray at comlab.ox.ac.uk> wrote:
> > The current features of the taxonomy are the following:
> > OS / Language - whether the system is an operating system or programming
> > language. e.g. EROS is an OS. E is a language.
> Perhaps there should be a third category: protocols. Plash's
> object-capability protocol would fit into that category
> (http://plash.beasts.org/wiki/PlashObjectCapabilityProtocol). It is
> OS-based but it is not an OS.
Wow, I'd totally forgotten about Plash. Thanks Mark.
Can I ask you a few questions since my memory of Plash is a bit foggy.
Suppose we have a single process running in a plash sandbox. That
process has its own object-capability server that it communicates with
to do anything in the system (open files, fork other processes etc.)
1. If it forks a new process, does the new one share the same server?
2. Do Plash servers ever communicate with each other?
On the assumption that 1. is true and 2. is false, each collection of
server+sandboxed-processes can be considered a single object-capability
In this case, the server is akin to an OS kernel and the chroot'd
processes that communicate with it akin to userspace processes, where
the system-call interface is a socket rather than an IRQ.
I'd then call Plash a virtual object-capability operating system, where
an OS instance comprises a server and the sandboxed processes it
Is that fair?
> Are you only considering pure capability systems?
I'm considering object-capability systems only. Unix file descriptors
over domain sockets have already been incarnated as an object-capability
system in Plash. Without the Plash chroots (and a healthy ignorance of
network access ;) one cannot call file-descriptors-over-domain-sockets
object-capability, I think.
Thanks for the info on how Plash fits into the taxonomy -- I'll include
it in just a sec. One question:
> > Recursive Reentrancy - whether the system automatically allows objects
> > to be recursively invoked, e.g. E does. EROS does not.
> Plash: yes.
Does this occur when I fork+exec a program binary P and it then
recursively execs itself so that both the original instance and the
recursively exec'd instance share the same namespace? If so, I agree
this is totally recursive reentrancy.
Plash would presumably also exhibit concurrent reentrancy. Suppose two
processes each have a program binary P in their namespace and each fork
+exec P, using the same namespace for P in both cases. Then both
insstances of P share the same namespace and we have concurrent
Does that sound fair?
> What do you mean by async send without async receive or vice-versa?
An async senc without async receive might look like:
asyncSend(cap,msg,replyCap); // done async (e.g. in another thread)
waitForRecv(replyCap,&msg); // block waiting for the reply
An async receive without async send seems a bit strange and I'm not sure
that it exists anywhere, although it can be easily modelled.
These sorts of situations can arise only in object-cap OSes, however, as
most languages are either just synchronous call+return, or implement
asynchronous calls that return promises. One doesn't tend to "wait" on a
promise but instead provide a continuation that will be executed when
the promise resolves. Hence, the "receive" here is done asynchronously
> Promptness of transfer, and whether messages need to be queued, is
> possibly another feature in the taxonomy.
That's a good point. I'd be happy to talk more about it and how various
systems would be categorised here.
> > EQ - whether the system provides an EQ implementation (even if it is not
> > universally available to all objects), e.g. EROS/CapROS do (via
> > Discrim), as do most languages (via '==').
> Plash: yes, but preserving identity is optional. When sending an
> object reference multiple times, a protocol implementation can (but
> does not have to) reuse the same object ID. Similarly, when receiving
> the same object ID multiple times, the implementation can choose to
> reuse proxy objects.
> Currently the Python implementation preserves identity but the C
> implementation does not.
I'll call that a yes.
Thanks heaps for your feedback Mark.
More information about the cap-talk