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.