Re: CE6.0 Driver Pointer Marshalling - passing pointers out only?

With regard to #1, VirtualAllocEx can be used to allocate memory in a specified process. Read/WriteProcessMemory can be used to access this memory (these apis aren't particularly fast). We don't generally recommend APIs working in this way.

-Ross

<andyraf@xxxxxxxxxxxxx> wrote in message news:1178857764.169292.259800@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On May 10, 2:35 pm, Dave Peverley <dpever...@xxxxxxxxxxxxxx> wrote:
Hi all,

First off, apologies if this is a repost - I think something
odd is going on with my news server!

I've got a pretty complex driver I'm porting up at the moment
and am stuck scratching my head over a slightly odd issue. I have
an API that talks to the driver via DeviceIoControl() with various
structures that relate to API parameters.

For all of the calls so far its been straightforward mapping
embedded pointers via CeOpenCallerBuffer() and CeCloseCallerBuffer().
However there's a particular API function where the app passes in :
UINT8 **bufferarray;
UINT32 buffersize;
UINT32 buffercount;

This is an array of pointers to (n) buffers that get set up
_by_the_driver_ and returned to the caller rather than passed
in. i.e. the app sets up the count and size parameters and then
the driver allocates the buffers (via an internal allocation
routine from its own block of reserved memory). So I can map
in the bufferarray to set the pointers up in, but I can't work
out how to map the allocated buffers back into the callers
process space.

Obviously to map the buffer back out via the CeOpenCallerBuffer()
idiom it would have to have been passed in in the first place which
it wasnt so I'm kind of stumped trying to think what the most correct
mechanism to do this by would be?!

Of course I understand that changing the driver so it doesn't work
this way is likely to be the first suggested answer but this is a very
large driver and API that is cross platform to various other OS's and
this isn't a feasible option sadly...

Has anyone else had to try and get around this or a similar issue
in CE6.0 yet?

Best Wishes,

~Pev

Ok, obviously you've already though of the most obvious solution,
which is to change the API (allocating memory in the kernel and
passing it back to the caller is not a great design).

Anyway, I think you basically have two options:

1. I think there's an API allowing you to allocate memory in the
caller's process space. Look up CeRemoteHeapCreate. I suspect this
won't solve your problem because it sounds like you need to map a
specific reserved area of memory to the caller, and I think Remote
Heaps are dynamically allocated on the client's heap (they basically
act as if the client code had allocated them).

2. Use VirtualCopyEx to map a region of kernel memory to the client's
memory space. This is most likely to solve your problem, and is
exactly what we do in things like DirectDraw when we need to map the
frame buffer into the client's address space. There are a couple of
things to keep in mind with this mechanism:
- The minimal size that is actually mapped is 64k, so lots of small
allocations will eat up virtual memory space and waste MMU entries.If
you need to pass back a bunch of small pointers to data blocks that
all share the same memory region, it's better to just map the entire
region once and then calculate the client addresses for each block
within the region yourself rather than calling VirtualCopyEx for each
small block.
- On ARMV4 processors, the OS will automatically disable caching for
any memory blocks that are aliased to two different virtual addresses
(which is what VirtualCopyEx does).

-Andy




.

Relevant Pages

  • Re: Which to use, AllocCoTaskMem or AllocHGlobal
    ... Looking at the DocumentProperties API I do not see that any of its ... parameters require the COM allocator, ergo I would not use AllocCoTaskMem, I ... MAPI has its own API calls for memory that I ... My understanding is that AllocCoTaskMem will allocate ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Working Set = Virtual Size, is it possible?
    ... Yes I guess that this is an option, this API ... to allocate non paged memory. ... Allocate address space with VirtualAlloc(... ... So far I've looked at SetProcessWorkingSetSize and VirtualLock. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Working Set = Virtual Size, is it possible?
    ... One option is to use the "Address Windowing Extensions" API to allocate your ... Allocate address space with VirtualAlloc(... ... Allocate physical pages of memory with AllocateUserPhysicalPages ... So far I've looked at SetProcessWorkingSetSize and VirtualLock. ...
    (microsoft.public.win32.programmer.kernel)
  • Tru64 issues with Infinite limits
    ... An automated test in my nightly build was failing due to Out of Memory ... Cannot allocate block 146 ...
    (comp.unix.tru64)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (alt.comp.lang.learn.c-cpp)