Subject: Re: map user memory in kernel
To: Jaromir Dolecek <jdolecek@NetBSD.org>
From: Bill Studenmund <email@example.com>
Date: 11/07/2005 09:48:25
Content-Type: text/plain; charset=us-ascii
On Sun, Nov 06, 2005 at 08:41:02PM +0100, Jaromir Dolecek wrote:
> On Sun, Nov 06, 2005 at 12:47:09PM -0600, Eric Haszlakiewicz wrote:
> > On Sun, Nov 06, 2005 at 12:45:43PM -0600, Eric Haszlakiewicz wrote:
> > > The problem is that the only way you have to recognize that you're=
> > > the intended target it with the userland address passed to sys_futex(=
> > > For this to work right, both proc's va's need to refer to the same
> > > underlying memory, so there should be either a vm_page or a vm_object
> > er.. I meant vm_anon, not vm_page.
> vm_anon is per-process thing, so we don't want to use that -
> we need to use the vm_page or vm_object.
Why not just use vm_object?
Create a pool of sleep objects. A sleep object contains flags and an
offset. When a thread goes into sys_futex(), grab one and tie it to the
vm_object. Turn the slept-on address into an offset in (vm) object, store
it in the "sleep object" and sleep on the address of the sleep object.=20
When we do a wakeup, find the vm_object corresponding to the address and=20
calculate the offset within object. Then go looking for objects sleeping=20
on that offset, and wake it.
Do we know if sys_futex() makes any wakeup promises? As others have noted,=
wakeup() can have spurious wakeups. If sys_fuxex() doesn't do that, then=20
we have to have something with a "yes, you really woke up" flag.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----