Re: Equivalent of Linux kmap on Mac OS
Re: Equivalent of Linux kmap on Mac OS
- Subject: Re: Equivalent of Linux kmap on Mac OS
- From: Terry Lambert <email@hidden>
- Date: Wed, 7 Mar 2007 16:03:58 -0800
On Mar 7, 2007, at 9:54 AM, Bhavesh Davda wrote:
Sorry for not providing more context.
Yes, what I'm looking for is something that has memory semantics (i.e.
I don't need to call map/unmap functions ever time I want to access
this piece of memory), where the memory is allocated in a user space
task, but should be accessible without these map/unmap calls like
"global" memory within a KEXT, for all tasks running the KEXT code as
part of a synchronous system call, and also for all kernel threads
running the KEXT code as some sort of a "bottom-half".
I understand that in the context of the userspace task that allocates
and owns the memory, the kernel (KEXT) doesn't need any special
mapping code to access the tasks userspace memory.
I'm also not looking for the bounce buffer element of Linux's kmap.
All I would like is a way to, through non-kernel-private APIs, be able
to map the userspace memory into the kernel map, so that all tasks can
access it in KEXT code.
You really want the device to own the memory, and then map it into the
user space process(es).
If you do it the other way, and the user space process restarts, you
are going to have a really hard time replacing the mapping in kernel
space (because it might be in use, and you just don't know) with a new
one from your process address space for the replacement process.
For example, if you were trying to implement a firewall with a user
interface component in a network extension, and mapped memory in from
a user space control process to communicate rules and status
information to the user space process, and potentially to communicate
information back to the kernel after popping up a dialog that said
something like "Application foo is attempting to access the Internet;
Cancel or Allow?".
If that user space process ended up dying it'd take all your current
rules state and historical status information with it; but you'd still
have a reference to the mapping to the vm region map in kernel space;
until that reference goes away, your mapping in kernel space would
stay around (it's there because you put it there, and it stay around
because it still has a non-zero reference count.
Now you start up a replacement control process; how do you transfer
the existing data into the new process? How do you replace the
mapping in kernel space now that the network extension is already
loaded, and you have active threads looking in the memory region that
came from the original process?
You are much better off having the kernel own the memory, and mapping
it into the user space process, instead of trying to go the other way
around. A minimal recovery strategy would require you to map the vm
region into the address space of the new control process, and if you
are going to do that anyway, then you might as well do that in the
first place, and make things a lot simpler for yourself.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden