[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Do we want a server on `/servers/machine' (or similar)?

From: Thomas Schwinge
Subject: Re: Do we want a server on `/servers/machine' (or similar)?
Date: Fri, 11 May 2007 23:45:45 +0200
User-agent: Mutt/1.5.11


On Thu, May 10, 2007 at 07:32:31PM -0700, Thomas Bushnell BSG wrote:
> Um, well, you could keep track of the relationship, and establish the
> rule that a user of i386_io_perm_create sent to this special server must
> keep the request port open as long as they want the mapping to stay
> alive.  

Wouldn't there be a way to just _move_ the send right to the freshly
created i/o permission kernel object to the target task (which is the
requesting task in this case)?  So far, I haven't been able to figure out
how to do that correctly.

Requestee R invokes `i386_io_perm_create' on the server S,
`/servers/io_perm'.  S invokes `i386_io_perm_create' on the device-master
port, which returns a new handle H to a freshly created kernel object.
Then S _moves_ H to R (*HOW?*) so that S itself won't reference H
anymore.  Then, as soon as R dies, H will become invalid and the kernel
will receive a no-senders notification.  Wouldn't it work that way?

> As for separating the memory access and the IO ports, is there any
> reason to want to combine them?

No hard reason, no.  They seemed to me to be somewhat related (they're
both machine specific in some way, but I agree that the memory access is
not really i386 specific) and I wanted to save the need for introducing
two new servers in `/servers/'.  But if having them separated is in fact
how you'd like it to be, then that's perfectly fine with me.


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]