Shared Chunks

Shared chunks

Device drivers often need to share data between user space and kernel space threads. Though there are APIs for doing this, such as Kern::ThreadRawRead() and Kern::ThreadRawWrite(), these involve an overhead of a memory copy, which can be a problem when there is a large amount of data.

To avoid unnecessary data transfer, Symbian platform provides shared chunks, which are similar to shared memory in other operating systems. Shared chunks can be created and used by both a driver and user-side code directly. An example application for shared chunks is for a camera driver. Without shared chunks, the image data would have to be copied from the camera driver to the user process, which would then copy it to the display driver. This would have a high memory copy overhead. Using shared chunks instead would improve the performance of the camera view finder.

A shared chunk is created and controlled by the kernel side code, for example, the device driver, rather than the user code. This memory is safe to be used by ISRs and DMA. A shared chunk can be mapped into multiple user processes in sequence or at the same time. The memory object can be transferred between another process and another device driver. Multiple drivers and multiple user processes can have access to the same shared chunk.

Comparison between shared memory and shared I/O buffers

The EKA1 versions of Symbian platform had a mechanism called shared I/O buffers. These are now deprecated, and shared chunks should be used instead. The disadvantage of a shared I/O buffer is that only one user process can access the chunk at a time, and that it does not have a user handle: the user process is only supplied with the address and size of the buffer. Shared chunks solve these issues, and give more flexibility for users to do safe operations.