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
