At Thu, 11 Jan 2007 15:22:40 +0000, Sam Mason <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
