Shared memeory between the user and kernel mode

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
We're looking for suggestions on the recommended method for sharing a
memory region (on the order of 1.5 meg)between user-level apps. and a
device driver in a high-performance application. The reason for sharing
the memory is to nterleave between (MPEG) hardware driver and the
library where either the user-level apps., or the device driver can
modify the shared memory region (using mainly atomic ops. and polling
to achieve the necessary interlocks). The shared memory must remain
resident, permanently allocated (at least as long as the apps. and/or
the device driver need it) and accessible from both the kernel and
user-level.

So far, we see some implementation alternatives:
1.Shared memory primitives
2.Use mmap(2) to map a file into the user address space and pin it into
memory

Related question:

1.is a device driver permitted to make system calls that for example
obtain/release a user-level semaphore (cf, semget(2))?

2.Is there a list somewhere, of driver do's and don'ts, listing allowed
system calls from a kernel-level driver?

3.We'd like to be able to use semaphores to synchronize access to the
shared mem. instead of a more elaborate atomic-op related scheme, that
requires polling when contention is detected, but whatever method we
use, it has to work inside the kernel-level driver as well in the
user-app. how?

4.What is the best approach for performing the mapping of kernel
mememory into user memory?

5.How should the user memory address space mananged (ie, how does the
driver determine where the memory should be allocated in the user
address space)?

6.Are there internal kernel functions that can be called to accomplish
most of the work, or do the page tables have to be modified directly by
the driver (that's what we're doing now)?

7.Are there any security and/or MP gotchas (we're familiar with how the
MP issues are handled in the kernel but are wondering what are the
non-obvious issues relating to page table management, etc. that we
should be aware of).

Best Regards,

kawshol


Re: Shared memeory between the user and kernel mode
Quoted text here. Click to load it

The standard way to do this is to implement the mmap() call in your
device driver. Framebuffers generally use this, and the X Window system
uses mmap() to render directly into the frame buffer itself.

Quoted text here. Click to load it

This is the wrong approach. Generally you don't want the kernel
interacting with userspace in this kind of way.

The driver probably does not need to autonomously operate on the data in
the buffer of it's own accord, so from that perspective, there should be
no requirement for locking. Instead, the system should be designed such
that your video hardware responds to commands from user space (eg via
ioctl()) which tell it to perform operations on the buffer. In this way,
the responsibility for ensuring that two conflicting operations on the
buffer do not occur is shifted out of the driver and into userspace.

Quoted text here. Click to load it

See Linux Device Drivers and implementing the mmap() call.

Quoted text here. Click to load it

No it does not, the virtual address which is mapped onto the physical
hardware address will not be fixed. Calling mmap() will return a pointer
to the address where the hardware can be accessed.

Quoted text here. Click to load it

Jeez, that sounds bad. Why are you messing with the page tables ?

Re: Shared memeory between the user and kernel mode
Hi Geronimo,

Ok I understand better now. mmap() is the way. I am newbie to the
linux.

I would rephrase the problem I have a MPEG hardware block that needs
the ~1.5 MB physical contiguous memory(fixed at a address). A user-land
library will fill the packets to be encoded to this memory space. The
hardware encoder will put back the encoded data to this space back.

My questions are.

1.Can I allocate a memory in the kernel space and using mmap() share
that with the user space? can I fix this space when kernel boots?
2.Can I set some asynchronous events that can be triggered on the
interrupt form the hardware( to write to frame-buffer)?(or I need to
implement the poll() in library?)

Best Regards,
kawshol


Geronimo W. Christ Esq wrote:
Quoted text here. Click to load it


Re: Shared memeory between the user and kernel mode

Quoted text here. Click to load it

I assume the buffer you're referring to is split into input and output
sections.

The trouble is that while you can use mmap() to make the buffer visible
from both user and kernel space, you also have to tell the driver each
time there is some more data ready to be encoded; also the driver has to
report back to userspace when a newly encoded packet is available. That
makes it slightly more tricky.

You might be better off with a more simple implementation using read()
and write(). It's a shade less efficient than a shared buffer, but
easier to understand.

Quoted text here. Click to load it

You can allocate RAM and share it this way certainly. But how does your
hardware access it - is it using DMA ?

Quoted text here. Click to load it

Why do you need to do that ?

Quoted text here. Click to load it

If you are looking to have userspace respond to an interrupt from the
hardware, then yes, poll() is generally the way this is done. You can
also use signals but that's a bit more messy.

Re: Shared memeory between the user and kernel mode
Thanks,

we have some solution, we keep aside some memory form the linux and
then we map this memory for the shareing using mmap.  In user-space and
kernel-space this memory can be accessed. Because the memory area is
just another memory pool is has to be managed separately (hence
propriety memory management). It  uses one the standard malloc()
function of Linux  to allocate the memory  pool.

we have split the interrupt in to two parts user mode a polling while
kernel mode just registers the event.

Thanks for the help.

Best Regards,
kawshol


Site Timeline