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

[Jed Donnelley]

At 05:16 AM 1/4/2007, Marcus Brinkmann wrote:
>Hi Jed,
>
>you have said three mails ago:
>
>   "All I'm arguing for is the ability to standardize the
>   object-capability model sufficiently to map from one system to
>   another - e.g. along the lines of the DCCS.  Any such general
>   mapping will automatically provide the needed standard and "smooth
>   out" any nuances between the systems, provided that the systems were
>   designed with virtualizable capabilities only.  If they aren't then
>   I regard their design as unwise - both from the perspective of
>   remote mapping and from the perspective of many other "wrapping"
>   mechanisms that we've discussed like membranes and delegation with
>   responsibility tracking."
>
>Either I completely misunderstood what you wrote above (maybe you can
>clarify),

Of course I wrote the above.  It seems perfectly reasonable to me.
Nothing in the more recent discussion dissuades from the above
position - though I acknowledge something could.  When you say:

>or you have now admitted in several ways that this is wrong.

Perhaps you could point out the ways.  Everything I've written
since writing the above seems to me to have been defending the
above position - which I regard as very important.

>Systems can not be designed with "virtualizable capabilities only",

 From my perspective you didn't argue that systems can not be designed
with "virtualizable capabilities only" from a functional perspective,
but rather that if they were then their performance would inevitably
be unacceptable.  What I argued in the last few days is that there
are means available to make the performance of such a system (in an
apples to apples comparison) indistinguishable from a monolithic
kernel implementation with an interface like the native Unix or
Windows interface.

>and there is no "general mapping" that "will automatically provide the
>needed standard and smooth out any nuances between the systems."  That
>was my whole point.  A system built on one set of mechanisms may
>require significant structural changes to run on another set of
>mechanisms according to its specification.

You might be interpreting what I said more broadly than I intended.
What I was arguing is that such a general mapping to a needed
standard can smooth out any nuances between suitably designed
object-capability systems.  That is if we, as a community, can
come to an agreement about what should constitute a "generic"
object-capability (and I believe it possible and important that
we do so) and if we insure that all our object-capability systems
provide mapping to such a generic standard, then we will add
value to our approach to computing.

What I was not trying to argue is that agreeing on such an
interoperable standard and providing for such a mapping in
all our systems will allow us to map Unix or Windows systems
onto any particular object-capability base without considerable
tension in performance and possible functionality.

>With regards to your performance claims, they are not helpful because
>you don't say what constitutes a "significant performance loss" for
>you

How can you say whether getting to within 10%, say, of the cycles
needed to perform a particular operation is close enough or not?
What we did in our community was to work the system until our
users were content.  I believe that's all any system designer can
do.  As I noted I believe we were working under particularly
onerous conditions:

1.  The requirement that even with our emulation of a legacy
system that we provide indistinguishable performance, and

2.  That we do so for a case that the system, even the legacy
system, wasn't designed to handle well - namely providing low
latency access to through the file I/O interface to solid
state memory storage.

The fact that we could do so without changing the wrappable
object-capability interface to me suggests that generally
the interface issues are not likely to be a fundamental
barrier to standardizing already similar object-capability
interfaces sufficiently to map them effectively - at least
at the network level where such a mapping is needed.

>and your optimism seems to come from additional design
>constraints, for example being able to move certain services into the
>kernel, which are not generally applicable.

Why not?

>I will reply to some technical notes in a separate note, without
>digging harder on this main point.

I'll take those up in response to your other message.

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070104/01e4ad99/attachment-0001.html