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

[Marcus Brinkmann]

At Sat, 30 Dec 2006 00:02:50 -0800,
Jed Donnelley <capability at webstart.com> wrote:
> 
> At 08:05 AM 12/29/2006, Marcus Brinkmann wrote:
> >At Thu, 28 Dec 2006 18:19:03 -0800,
> >Jed Donnelley <capability at webstart.com> wrote:
> > >
> > > At 05:34 PM 12/28/2006, Jonathan S. Shapiro wrote:
> > > >On Fri, 2006-12-29 at 01:25 +0100, Valerio Bellizzomi wrote:
> > > > > >Precisely. If the model ignores this, it's both 
> > non-believable and fails
> > > > > >to model observability correctly.
> > > > >
> > > > >
> > > > > Can you expand on Observability ?
> > > > > I will read your reply tomorrow, heading to bed now :-)
> > > >
> > > >Suppose that I (a keeper of the space) can write a mapping slot. You (a
> > > >client of the space) cannot read the capability in that slot, but you
> > > >can traverse it. By reading the thing that it points to, you can
> > > >determine that the capability in that slot has been altered.
> > >
> > > On a meta note I'll mention that I'm often unhappy with what I
> > > regard as the varied nuances of descriptor type object-capability
> > > operating systems because they can provide so many different
> > > sorts of capability communication mechanisms.  The implementors
> > > of such systems seem to regard this opportunity to vary the
> > > interface as valued flexibility.  To me it argues against
> > > consistency in the object-capability paradigm and works against
> > > any hope for a consistent object-capability message.
> >
> >It's undeniable that such fragmentation occurs whenever the capability
> >model hits the real world.  We have too many examples.
> >
> >To me this suggests that the greatest common divisor of all capability
> >models is simply insufficient to solve many real world problems.
> >Think of the nuances as bug fixes.
> >
> >I can understand your dismay at this conflict, but I have my doubts
> >that the solution is to "fix" the real world rather than the
> >capability systems.  Economy of mechanisms is an important goal, but
> >not for the sake of the mechanisms themselves.
> 
> 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.

I understand, but some goals are just pipe dreams, and not attainable
in the real world.

> 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.
> 
> I regard this virtualizability as relatively easy to achieve if it
> is considered worthwhile from day one.  I don't believe there are
> any fundamental issues with it.  E.g. I don't believe it conflicts
> with any need to provide flexible memory mapping mechanisms as
> Shap. seems to suggest.

Well, make a proposal for such a set of fundamental mechanisms that is
sufficient for all large scale systems built on it.  Given that you
don't consider resource allocation issues a serious concern I am
however doubtful that your confidence in this matter is on solid
grounds.  I have thought quite a bit about the differences in the
design of OS level features and I don't see a common set of
fundamentals that would be sufficient for all large scale systems
built on top of them.

You are asking for no less than the holy grail in operating system
research, something that has been proposed many times in the last
decades but never accomplished.

Note that I have no problem envisioning such a solution for a set of
high-level applications with no critical demands with regards to
operating system resources.  As soon as you ignore issues of timing
and resource allocation, it all seems very easy, and the solutions are
reasonably well understood.  But not all applications belong into this
category, in fact, in my opinion fewer and fewer do.  Google tries
very hard to keep response time of their web service below a certain
critical threshold (couple hundred of miliseconds).  There is a reason
for that, and that reason applies doubly to interactive computing
environments of all sorts.

Thanks,
Marcus