Media Driver Migration Guide

Purpose

This document explains the points that have to be considered when migrating existing media drivers to a writable data paging environment.

Issues Involved

The two main issues that have to be addressed when migrating existing media drivers are:

• A deadlock condition can occur between the driver and the client process, where both are trying to access the same page of paged memory

• A deadlock condition can occur between the driver and the client process, where the client is allocating on the kernel heap, the paging system tries to page out some data and the media driver also tries to allocate on the kernel heap while servicing the resulting request.

• Unpredictable delays in servicing a DFC can occur, since memory might need to be paged in.

To address the above issues, the following points will have to be considered/undertaken:

• Pass data by value to DoRequest/DoControl

• Return results by using a return code

• Use of a dedicated DFC queue

• Determine if unpredictable delays in servicing DFCs are acceptable

• Validate the arguments in the client context as far as possible

• Move user memory accesses to client context where possible

• Replace the use of small fixed-size structures with the use of the TClientDataRequest object

• Pin user memory accessed from DFCs

  Do not allocate on the kernel heap while handling page out requests.

  The paging algorithm can be over ridden and pages of memory can be kept in memory (pinned). This situation can be reversed by 'unpinning' the page. The TClientBufferRequest API provides this functionality.

• Re-write the driver to use shared chunks

• No fast mutex may be held when calling APIs that access user memory

• No kernel mutex may be held

• Use the new APIs, (See the Writable Data Paging Overview ).

See also

• Device Driver Writing and Migration Guide

  This document explains techniques for writing device drivers on data paged systems and migrating device drivers to data paged systems.