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.

+ + + + + +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.

\ No newline at end of file