Re: Reserved Memory Access Question CE 6.0 vs. 5.0

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

If you want to do the allocation in the driver, check out VirtualAllocCopyEx
and friends (meaning the Ex versions of the Virtualxxx functions). I
haven't actually done this, but you should be able to allocate memory in the
calling process.

K.S.'s mechanism had the allocation done in the application, and the driver
then mapped it into it's own process space. I don't think that will work in
this case since you're trying to specify the physical address.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"FoolBlah" <foolblah@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:67899EE3-E52E-4B96-9CBE-1E59A4BFC2D6@xxxxxxxxxxxxxxxx
I'm not sure I follow, but it may be the language barrier fouling me up...

I would like to be able to map to the reserved memory region specified in
config.bib as I did before in CE 5.0. A contiguous block of memory *is*
important, and previously being able to map to this reserved memory
gauranteed this.

I was just thinking about this... the data is only read via the user mode
application however it is written via flyby DMA and I am hoping I won't
have
access problems writing the data as well. I am thinking not because this
is
all handled in the kernel mode ISR.

Thanks.

"K. S. Huang" wrote:

If a contiguous memory with fixed/unknown Virtual and Physical Address
*not*
a mandatory for you but only need a shared memory, you may allocate a
memory
in you User Application and than pass the pointer to your kernel mode
driver
and then the driver using CeAllocAsynchronousBuffer API with
MARSHAL_FORCE_ALIAS flag to create a alias memory mapping.

"FoolBlah" <foolblah@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BC72225A-6817-4B01-ADCE-A9F67914D6CA@xxxxxxxxxxxxxxxx
I have a custom driver that I am porting from CE 5.0 to CE 6.0. The
driver
utilized the "openness" of the old memory architecture in that driver
was
loaded via the application, and mapped all of the hardware resources
via
MmMapIoSpace().

I have broken the driver apart into a basic upper level pass through
wrapper
API library that is still loaded via the application. This wrapper
does
all
of the DeviceIOControl() calls to a new stubbed out stream driver that
is
loaded into the kernel memory space. This was to get around the CE 6.0
memory architecture changes.

All went well, but there is one item that is now hanging me. I had
allocated a large block of memory in config.bib (16 MB) that I then
mapped
into the application via MmMapIoSpace(). The old driver simply passed
this
data pointer up to the application and all was peachy. However, this
data
pointer is now mapped in my new stream driver and the pointer is still
passed
to the application via the DeviceIOControl() calls. Obviously this
causes
the application to generate an access violation exception when this
data
is
accessed being that it was created in the kernel memory space and is
being
accessed via a user space application.

So... how can I map this reserved memory space into the application
user
space so that I can use this data blob as I did in previous versions?
FWIW,
it is not possible to copy and/or modify this data in any way due to
performance implications. The prior implementation has worked
perfectly
for
years, I was always guaranteed that the memory map would be successful
since
the memory was reserved, and there was no need to move this massive
amount
of
data around while processing.

Thanks.





.

Relevant Pages