Re: capability address space and virtualizing objects

[Neal H. Walfield]

At Thu, 28 Aug 2008 16:34:13 +0200,
Tom Bachmann wrote:
> Erm, are you sure that this kind of feature is required? Allowing the 
> address translation process to be extended in such a way is a somewhat 
> orthogonal issue imho (though of course there are interrelations as you 
> show) opening a completely new realm of problems. I'm not convinced that 
> you want to do that. Are there compelling use case?

The problem isn't extending the address translation mechanism, it's
the ability to fully virtualize an object.  On a system like Mach,
this is not a problem because address space construction is not
exported to user space so there is no need to virtualize this
functionality.

The ability to virtualize objects is useful, for instance, for
implementing rpctrace.  If we could only virtualize non-kernel
objects, then a program could invoke a capability in a cappage that it
got in a message.  If rpctrace does not proxy cappages, it would not
see any invocations on them.  The solution here might be to simply
proxy the capabilities aggressively (i.e., proxy all reachable
capabilities in any message).  But that can mean a lot of memory!
Also, it would require detecting capability cycles, which is hard.

Neal