Mathieu Routhier wrote:
In the “Sending this IRP” section, it says:
[the called should] deallocate the IRP and the INTERFACE structure when they
are no longer needed.
Why define a referencing/dereferencing system then?? I would have expected
the InterfaceDereference function to be responsible for freeing the
INTERFACE when the reference count reaches zero (just like COM!). Not one
of the caller, who does not know the current reference count…
Sigh. That seems like more misleading doc. I think you’d normally use a
synchronous IRP_MJ_PNP to send this request down the stack, and the
system will clean it up. There’s no need for you to “deallocate the IRP”
at all in this situation. If you use an asynchronous IRP, you’ll call
IoFreeIrp in your completion routine. This is just normal IRP handling
– there’s nothing additional or special about it being a
QUERY_INTERFACE request.
As far as telling you to deallocate the INTERFACE structure, this is
just gratuitous advice in my view. You’re probably going to put that
structure into your DEVICE_EXTENSION structure, and it will go away
pretty much by default. Even if you allocated the structure specially,
telling you to deallocate it when no longer needed seems to assume you
might, but for the admonition, be tempted to deallocate it while it was
still in use. I don’t think so…
The doc is misleading when it says that a driver “returns” an INTERFACE
structure. It does not. It *fills in* an INTERFACE structure that you
provide.
The reference/derefence protocol is so that whoever implements the
interface can know when there are no longer any pointers outstanding to
the functions in the interface, basically so he can know when it’s safe
to unload. That implementer does *not* keep a pointer to your INTERFACE
structure.
I would also quarrel with the blanket statement “A driver that handles
this IRP should avoid passing the IRP to another device stack to get the
requested interface.” The ostensible reason is that “such a design would
create dependencies between the device stacks that are difficult to
manage.” Yet, later on, they tell you how to use
IoRegisterPlugPlayNotification to avoid these dependencies. Furthermore,
I think a multifunction driver pretty much *must* repeat this IRP on the
parent driver stack to let child function drivers get at the underlying
bus.
–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com