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: Anton Altaparmakov <email@hidden>
- Date: Wed, 7 Mar 2007 22:14:12 +0000
On 7 Mar 2007, at 17:54, 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.
Hopefully this makes the intent more clear.
Yes perfectly clear. In that case forget everything that I said and
listen to what Mike and Terry have to say. (-:
Best regards,
Anton
Thank you!
- Bhavesh
On 3/7/07, Michael Smith <email@hidden> wrote:
On Mar 7, 2007, at 3:45 AM, Anton Altaparmakov wrote:
> If you are not working with a file system then I would suggest
> checking out what ubc_upl_map() does and following it up that way
> to figure out what to do analogously.
That's probably not a good suggestion; the UBC implementation does
not use KPI. If the page is sourced from an address space (as I
inferred from the Bhavesh's original request) then there's no need to
construct the UPL (it will happen automagically if the page has to be
faulted in).
What this boils down to, again, is that without more information on
what Bhavesh actually wants to do (i.e. not "there is this call in
Linux"), we're not really able to help him very much. 8)
= Mike
--
Bhavesh P. Davda
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
_______________________________________________
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