[cap-talk] Another "core" principle - virtualize capabilities

[Jonathan S. Shapiro]

On Thu, 2007-01-04 at 21:08 +0100, Marcus Brinkmann wrote:
> At Thu, 04 Jan 2007 09:36:36 -0500,
> "Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> > 
> > On Thu, 2007-01-04 at 14:16 +0100, Marcus Brinkmann wrote:
> > > Systems can not be designed with "virtualizable capabilities only",
> > 
> > Marcus: why do you believe this? Jed and I certainly disagree.

Urk! That should have read:

  Jed and I certainly agree that it can be done.

> I guess it depends on what you mean by "virtualizable capabilities
> only".  It seems to me that any complete system will eventually depend
> on details that Jed, for example, considers to be orthogonal to the
> capability system.  Things like how the scheduler behaves, for example.

I think we are using terms differently -- and this is why I don't like
to use the term "virtualizable" for this.

What *I* mean by virtualizable in this discussion is that you can take a
capability, front-end it with a process that implements the same
protocol, and the caller cannot tell the difference based on the
behavior.

Jed sometimes talks about simulating one capability system on top of
another. I actually don't think that your scheduler issue is a real
objection. You may need to implement a new scheduling discipline on the
new host system, but you can still talk to it in capability fashion. The
issue that I think is more serious is the need for the two systems to
agree on the details of the transport-level payload of an invocation,
the mechanism of reply (resume caps? sessions?), [a]synchrony, and
blocking behavior.

All of these behaviors can be compatibility simulated with enough work
at the library level, but at that point we are no longer virtualizing
the capabilities themselves (which is a kernel-level thing). We are
instead virtualizing the capability invocation API (which is a
user-level thing).

> I understand that the capability model can be extended until it gives
> a complete model of computation which more or less deterministically
> describes the behaviour of the system as a whole.  But it seems to me
> that this includes many details that are usually considered to be
> orthogonal or outside of the capability system, or, if not that, then
> at least these details go way beyond what is universally agreed upon.

Yes and no. As a *model* I agree fully with Jed, because for modeling
purposes it is sufficient that one system can be described in terms of
the other. For practical emulation, I agree with you, because the
details of these decisions have overwhelming impact on real performance
in important cases.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100