site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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. Best regards, Anton Thank you! - Bhavesh 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. (-: On 3/7/07, Michael Smith <drivers@mu.org> wrote: This email sent to site_archiver@lists.apple.com