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.

+ + + + + +Shared +ChunksThis document describes the use of shared chunks to share data. +

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.

\ No newline at end of file