Media -Driver Guide

Purpose

This document explains the points that -have to be considered when writing a media driver in an environment that uses -writable data paging.

Issues to consider

The main issue to consider when -writing a media device driver for a writable demand paging environment is -to avoid page faults from occurring in DFCs, since this can lead to a deadlock -condition between the driver and the client process.

This can be avoided -using the following methods:

Use shared chunks.

Shared -chunks are memory areas that are accessible by both kernel-side and user-side -and they are never paged.

This is the best solution for drivers that -involve fast throughput such as media drivers.
Use synchronous rather -than asynchronous data transfer

This could be done by implementing -the following steps:
1. The client requests -a notification when data is available.
2. The data arrives.
3. The driver writes data -into an internal buffer and completes the client request.
4. The client makes a read -request.
5. The driver writes the -data back to the client in the client thread context.
This approach is easy to implement, however it requires the buffering -of data.
Use the flexible -memory model

This provides the ability for the memory to be -mapped into a drive's address space as unpaged.

This is an alternative -to the use of shared chunks.

However, this is not supported on the -moving or multiple memory models.

See also

Demand -Paged Device Drivers Writing Guide

The above document is an -guide writing to device drivers.

+ + + + + +Media +Driver GuideDescribes the issues that need to be considered, when writing a +media device driver for a writable data demand paging environment. +

Purpose

This document explains the points that +have to be considered when writing a media driver in an environment that uses +writable data paging.

Issues to consider

The main issue to consider when +writing a media device driver for a writable demand paging environment is +to avoid page faults from occurring in DFCs, since this can lead to a deadlock +condition between the driver and the client process.

This can be avoided +using the following methods:

Use shared chunks.

Shared +chunks are memory areas that are accessible by both kernel-side and user-side +and they are never paged.

This is the best solution for drivers that +involve fast throughput such as media drivers.
Use synchronous rather +than asynchronous data transfer

This could be done by implementing +the following steps:
1. The client requests +a notification when data is available.
2. The data arrives.
3. The driver writes data +into an internal buffer and completes the client request.
4. The client makes a read +request.
5. The driver writes the +data back to the client in the client thread context.
This approach is easy to implement, however it requires the buffering +of data.
Use the flexible +memory model

This provides the ability for the memory to be +mapped into a drive's address space as unpaged.

This is an alternative +to the use of shared chunks.

However, this is not supported on the +moving or multiple memory models.