[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 |
Hello!
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.
Regards,
Thomas
signature.asc
Description: Digital signature
Re: Do we want a server on `/servers/machine' (or similar)?, Roland McGrath, 2007/05/13