| How can I test if a IOMemoryDescriptor references memory outside of the 32bit range?
Here is the problems I am having.
Our kext accepts requests from our IOUserClient interface. These requests can request that a large amount of data be read from the disk and returned to the client (the kext is an override of IOBlockStorageDriver).
The request is conveniently placed into the IOExternalMethodArguments. When the request is large then the structureOutputDescriptor arranges to have the memory map of the data from the client (at least I am assuming so).
This seems to be a good way of reducing memory usage by not double allocating and copying memory.
We are however finding that the IOMemoryDescriptor included as the structureOutputDescriptor can be outside of the 32b range. In some cases we think that the structureOutputDescriptor may also traverse more than one physical segment.
Our library assumes a pointer and contiguous memory for some functions. I am trying to accommodate those requirements when needed by checking for these situations. - Does the structureOutputDescriptor include multiple segments
- (and now) that the structureOutputDescriptor is out of the 32b range.
I am using getPhysicalSegment( offset, &length ) to count the segments. This causes a panic when the buffer is outside the 32b range.
I'm now looking and wondering if getPhysicalSegment( offset, &length, kIOMemoryMapperNone ), would avoid the kernel panic, and let me test for 32b addresses?
In the perfect situation, the memory mapped request from the client would be used for structureOutputDescriptor, then be passed along to the disk driver to read from the disk.
Now I need to test for the descriptor being out of the 32b range and allocate a shadow buffer and copy over. For one case, I need to ensure that the buffer is contiguous as well.
Am I doing this right?
Thank you for your insight.
...Duane
|