取消IRP--1

Cancelling IRPs

 FAQID1301     2002-05-31
 
Q: I\'m trying to figure out how to cancel an IRP waiting for a controller object but I am finding it a lot more difficult then I had imagined.  

 
 
A: Cancelling IRPs Waiting For Controller Objects

This technical tip started out a lot more attractive, but as with most things involving cancel routines in Windows NT kernel mode drivers, it got a little ugly. The approach presented here is viable, but its complexity would most likely make it appropriate only in circumstances that demanded it. In laying out its solution, however, this tip does discuss some interesting aspects of controller objects and cancel routines.

Controller objects can be powerful tools when designing Windows NT kernel mode drivers. They offer the ability to synchronize driver resources between different device objects within the driver. To this end, each device object can queue a request on the controller object using the function IoAllocateController. When the controller becomes available to service the needs of that device, a callback routine will be invoked. At this point, the device that receives control owns the resource and can perform its work. If this can be done within the context of the callback routine, the device can return DeallocateObject, allowing the controller to go on to service other requests, or it can return KeepObject, and at some later time call the function IoFreeController.

Typically, there may be several devices in a driver that each contend for the resources managed by the controller object. For example, a piece of hardware may contain two separate subsystems, but have only one interface that must be shared between them for control. Architecturally, it may make sense to model each subsystem as its own device. The shared interface could be managed with a controller object, allowing the two devices to exist independently of one another.