Media +Driver Migration Guide

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