Understanding Memory Descriptors
Understanding Memory Descriptors
- Subject: Understanding Memory Descriptors
- From: Duane Murphy <email@hidden>
- Date: Mon, 09 Nov 2009 10:50:43 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I'm wondering if there is a way to "recover" an equivalent memory
descriptor from a memory descriptors virtual address.
Here's more detail.
We use a user client interface to pass a large buffer to the kernel to
read some data. This buffer is allocated in user space and passed into
the user client to become the structureOutputDescriptor of the
IOExternalMethodArguments.
Due to our cross platform interface, this buffer is converted to a
memory address and length using. The memory address is determined
using IOMemoryDescriotor::map() and getVirtualAddress() on the
resulting IOMemoryMap.
Later this self same address must be used to read data from the disk.
This is accomplished using IOMemoryDescriptor::withAddress() using the
virtual address determined previously.
Would this second memory descriptor be fundamentally equivalent to the
first? Using the same addresses etc? Is there a way of making that
happen? My fear is that this process is contributing to virtual memory
fragmentation or at least not making the best use of available virtual
memory. It appears that in some cases this process fails when creating
the second IOMemoryDescriptor using IOMemoryDescriptor::withAddress().
The proper solution would, of course, be to be able to get the
original memory descriptor to the IO routine. Unfortunately that may
prove to be rather difficult given our cross platform engine.
Thank you for any suggestions and insight to the workings of
IOMemoryDescriptors,
...Duane
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.10.0 (Build 500)
Charset: US-ASCII
wsBVAwUBSvhkjUrg9acQ4r2CAQjsKQf/dAoyMQISsrNBv6ylyia7rBnmJ5jmccGq
AtQW2eEvblZM3w9Hdl7BF/ZTjVI/FZ1khFcZKq3Eb2EWEniKI67G8jgcuW6PktJc
IhBOxNQRXJMvtPsHShTXYwGA386/n1fSX3VrKh4tk2AAEt9K1GcqcWHBaZ7aFBo3
yEDMuhmGDvjTZJLamISPPa4Zu6tzIflVIUNlQYj+sFvGHuV6yVMd/U/e2Oajq2gx
Ek47UBJ9qKH4UagTmpBe962QTyvGhmzaA1NX0EXPhrAT4+Mm3TaPWakWVHxU33HV
ebcVDV3in63WgHbfMfvOfuri9RTo/Cww85KTD1ifzs5+9Gk5hvoy0g==
=C4pP
-----END PGP SIGNATURE-----
_______________________________________________
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