Re: Translucent storage: design, pros, and cons

[Marcus Brinkmann]

At Thu, 11 Jan 2007 15:22:40 +0000,
Sam Mason <address@hidden> wrote:
> 
> On Thu, Jan 11, 2007 at 12:48:11PM +0100, Marcus Brinkmann wrote:
> > My confusion in other areas of the design space is also a reflection
> > of the confusion in the research community on these issues.  One could
> > also call the confusion an opportunity to make choices.  Capability
> > MAP vs COPY, membranes (or not), active/passive objects etc are merely
> > some examples for this.
> 
> I think I understand the distinction between MAP vs COPY of
> capabilities, but I'm uncertain what "membranes" or "active/passive
> objects" are.  Are there any references to descriptions of these?

Membranes have been recently discussed on the cap-talk mailing list.
http://www.eros-os.org/pipermail/cap-talk/2006-December/thread.html
Good luck trying to get anything out of the archive, it has been a
very wild ride.  Let me just restate the basic question that one is
facing and leave it at that.

If a selectively revocable capability is invoked in an RPC call, and
the remote procedure returns a capability as an out parameter, what
should be the durability of this capability be with regards to the
invoked capability?

The most general answer seems to be "it depends", the second best
answer is that the returned capability should have its life time
dominated by the invoked capability.  Currently, there is no efficient
way to do that in either L4 or Coyotos.  Functionally, this can be
implemented with a reference monitor, and this may be sufficient if
your model is capability COPY and interposition is discouraged by
design.  But if your model is MAP, then this issue is more pressing in
my opinion.

For active/passive objects, the typical reference would be Bryan Ford,
Evolving Mach 3.0 to use migrating threads, 1993.
http://www.brynosaurus.com/pub/os/thread-migrate.ps.gz
The issue there is what the execution model is.  Current microkernels seem
to be aligned on active objects, but I heard rumours that this is
reconsidered in some places.  These (and other) issues are quite
fundamental.

As Jonathan said a year ago on this list, OS design is one of the most
constrained fields in computer science.  Despite, or because of this,
there are endless variations of the same basic functionality, with
sometimes dramatically different properties.

Thanks,
Marcus