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 memoryRelated 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