Re: Shared memory between kernel driver and multiple processes
- From: "Dean Ramsier" <ramsiernospam@xxxxxxxxxx>
- Date: Tue, 14 Nov 2006 20:18:39 -0500
I guess I don't see why you are concerned about physically contiguous
memory. AFAIK, VirtualAllocCopyEx() doesn't have to be used with physical
memory addresses. It operates generically on virtual memory. That virtual
memory, when committed, will be backed by physical memory. Might not be
contiguous but you don't care. Its ability to map in specific physical
addresses is a special case.
The bigger issue I think will be keeping the memory coherent. You'll have
to be careful to make sure your different processes are properly
synchronized with the backing memory. That won't be easy if you have a
virtually tagged cache such as exists on the ARM cpus unless you map in the
memory as uncached.
Memory mapped files are created just for this scenario (sharing data buffers
between multiple processes) and will handle the data coherency for you.
--
Dean Ramsier - eMVP
BSQUARE Corporation
"voidcoder" <voidcoder@xxxxxxxxx> wrote in message
news:emqbvpDCHHA.1240@xxxxxxxxxxxxxxxxxxxxxxx
In case you are talking about CE 6.0 (otherwise I can't explain
what VM routines like VirtualAllocCopyEx() do in your solutions
1 and 2), you don't have too much choice here. Either allocate
physically contiguous region in your kmode driver and map it to
the process, or use file mapping to map physically discontinuous
virtual memory.
Olivier M wrote:
Hi all,
I would like to allocate memory from a kernel driver (not necessarily
at driver load time) and arbitrarily map the memory to client
application processes. The memory must be readable and writable from
all processes that it's mapped to as well being accessible within the
kernel driver.
I have an idea about possible solutions but would like to understand
better what's best practice / possible etc.
- Solution 1: for kernel driver:
AllocPhysMem() gives a CPU relative physical address + Kernel CPU
virtual
VirtualAllocEx/VirtualCopyEx reserves arbitrary space in client process
and maps the physical address range to it.
-> This solution seems workable but relies on physically contiguous
memory - issues beyond boot time.
- Solution 2: for kernel driver:
HeapCreate()/HeapAlloc() create a kernel heap and allocate kernel CPU
virtual addresses from it
Use VirtualAllocCopyEx() to re-map memory to processes.
-> This solution doesn't depend on physically contiguous memory but I
doubt it's valid for VirtualAllocCopyEx to operate on kernel heap
allocations?
- Solution 3: File Mapping:
CreateFileMapping() / MapViewOfFile - kernel driver manages
allocations in a File mapping
User application processes can access kernel allocations in the file
mapping and have read/write access
-> Doesn't rely on physically contiguous memory although is not an
'orthogonal' solution compared to the way this is achieved in other
OSs (e.g. Linux). To give some background, WinCE is one of many OS
supported in a generic Driver Porting Software framework.
Any Feedback or advice is welcome
Thanks,
Olivier
.
- Follow-Ups:
- Re: Shared memory between kernel driver and multiple processes
- From: Sue Loh [MS]
- Re: Shared memory between kernel driver and multiple processes
- References:
- Shared memory between kernel driver and multiple processes
- From: Olivier M
- Re: Shared memory between kernel driver and multiple processes
- From: voidcoder
- Shared memory between kernel driver and multiple processes
- Prev by Date: Re: FIQ , Prefetch handling in WINCE (on arm processor)
- Next by Date: How to get USB / Ethernet (NIC) working on MS Windows CE 5.0 ?
- Previous by thread: Re: Shared memory between kernel driver and multiple processes
- Next by thread: Re: Shared memory between kernel driver and multiple processes
- Index(es):
Relevant Pages
|