Re: proxy memory objects

Marcus Brinkmann <[email protected]> writes:

> On Wed, Nov 20, 2002 at 09:49:29PM -0800, Thomas Bushnell, BSG wrote:
> > I don't think this makes sense.  What task?
> 
> Yeah, I know that this was bogus, too.  But we have to send it somewhere.
> Maybe it should be mach_host_self to specify the kernel which creates and
> holds the proxy memory object.
> 
> > I think we should send it to the memory object, that's the only thing
> > that makes sense.
> 
> I agree that this is ok, if you want that additional level of indirection.

I think this is right, because I think it's clearly what the *right
thing* will do.  In fact, the kernel doesn't actually need to be
involved with proxy objects *at all*!  Oh geez, now that I see this,
it's all so clear.

So the idea is to send a message to the memory object saying "give me
a restricted clone of yourself".  Right now, we will implement this
with a hack: a special call to the kernel that returns a special fake
memory object which implements the restriction implicitly at vm_map
time.

And the correct implementation will be for the pager itself in a
separate library, or with the aid of a helper process, to provide the
restricted clone.

> > *THEN* the memory object should have a special hack call to the
> > kernel--to the memory object control port--that creates the actual
> > proxy object.
> 
> This was the first thought I had when I realized that the memobj RPC
> doesn't go the kernel.  But the memory object control port doesn't exist
> before the first mapping is established.  It is for controlling a memory
> object that is actually used by the kernel.  The memory objct we have
> created is probably not used until we gave out the proxy object.
> Or did I misunderstood that?

Yes, you're right about that.  Since asking the kernel for the clone
is a hack anyhow, it doesn't much matter what interface we use to get
it.