Re: proxy memory objects

On Thu, Nov 21, 2002 at 11:37:00AM -0800, Thomas Bushnell, BSG wrote:
> 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.

Sure, I agree, that's very clear once you put it that way.
 
> > > *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.

Yes.  Well, using the task is justified if the kernel could at least
theoretically associate the port with the task, ie if it could use resources
in the tasks ipc space to allocate the port for the proxy memory object. 
Even though the current implementation doesn't do that at all, the vague
idea of something like that was what caused me to use the task as the
recipient.  But using the host does make at least as much sense (or just as
little), and I don't really care much.

BTW, for now, I will only add the hack.  The reason we can live with that is
that the filesystem itself will create the proxy object in our
implementation, and so a call to the memory object would just be a local IPC
anyway.  If we ever want to create proxy objects from a memobj that doesn't
belong to us, it is easy enough to add the extra indirect call to the memory
object interface. 

However, I think I will change the function name of the hack to
mach_create_memory_object_proxy, to illustrate the target of the RPC better
and leave the memory_object_* name space to the memory object (and control)
interface.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    [email protected]
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/