Hi,

The sys V functions, shmget(), shmatt(), and shmdet() allow
memory to be shared between one or more applications in userspace. The memory may be efficiently accessed in each
user application by dereferencing pointers.

Will this work between driver code and userspace?

If not, is there another method whereby memory can be shared between a device driver, and user code using pointers?

I am writing a display driver, and want to share the pixel image between user code and the display driver.
The user code will simply update the pixel image by dereferencing a pointer, and the driver will be responsible for keeping the display up to date.

Thanks for any information,

Ian Davidson

I would obligate the user to allocate a shared-memory segment and then provide you with a handle to it. With each request you then verify that the segment exists, that it really does belong to this user, and that it is of sufficient size, and that the coordinates are plausible. Then, the kernel-mode routine can gain access to the memory (caution: it's virtual!) and use it.

Needless to say, the interface to your kernel module will reside in a library that the user will employ to actually get at whatever functionality you provide. So, all the shared-memory strangeness can be wrapped-up in that "cleverly designed, easy-to-use" library. Although this does not relieve your kernel-routine of the obligation to validate its parameters on the assumption that some "133t h4x0R" has hijacked it, it does allow you to design some fairly crufty kernel-interfaces and get away with it.

Have you considered creating a character or /proc device and mmaping it from user-space? With a memory map the module will receive the updates; therefore, it will only need to refresh, etc. when the image is updated in the map. Leaving the data in user-space will probably require the module to be on a refresh cycle because the module won't know exactly when that memory has been updated, unless of course you require a "refresh" call from user-space (which might be more appropriate, maybe via ioctl.) Using a special file will also allow the module to arbitrarily limit write access.
ta0kira