Re: IRP_MN_WAIT_WAKE concurrency by Bill
Bill
Thu Oct 12 20:45:33 CDT 2006
You are going down a path I went down about what 7 or 8 years ago when
Win2000 was first coming onto the scene. You seem to have a good grasp of
what is going on btw. However, you are going to find that when you start
looking at PnP and Power together that there are some rather huge holes in
the documentation. In fact you are bumping up against the edges now.
Interestingly enough, Microsoft seems to have only bumped up against this
relatively recently, like in the last 3 years or so when they worked through
the new KMDF code. This caused them to state machine the whole mess and
they ended up with a HUGE state machine (~250 states). Of course, they took
into account every possible type of hardware, bus, idle methodology, etc.,
but still I would suspect even they were surprised by the complexity of the
driver model that had been created.
Unfortunately, there are several interdependencies between PnP and Power
which have never been documented (to my knowledge anyway), even though now
they are known (within the KMDF team at least). This is one reason I was
really hoping that the KMDF folks would release their source (as was their
stated intention at the start of their framework development). It appears
to me that that is never going to happen now. Nor do I believe that there
is any interest in passing their power and pnp learnings along, even though
Microsoft has been complaining for years about the quality of 3rd party
drivers. I believe it is Microsoft's intention to force us all to use their
new 'model', KMDF, for all future driver work and to leave the details to
them. This seems to me to be the case because I have already heard talk on
these newsgroups about WHQL requirements for KMDF in some miniport drivers
(HID I think), although this seems as yet unrealized. I hope I am wrong on
several counts here, and my suppositions are purely that.
Anyway, I thought you should know what you are up against as far as PnP and
Power are concerned. Do what you can, but you will always be hobbled by
undocumented dependencies that you could not possibly know about or
discover.
Bill M.
<BubbaGump> wrote in message
news:vvvqi2djjc36vhd1udied0kbi60ai4o7ln@4ax.com...
> The description of IRP_MN_WAIT_WAKE in the DDK says that it shouldn't
> be sent while any set-power or query-power IRP is active in the device
> stack. How is this usually done? A queue? Are all set-power and
> query-power IRPs, along with IRP_MN_WAIT_WAKE, supposed to be queued
> to be handled one at a time by a worker thread? (handling the
> specific device power IRP associated with the current system IRP
> immediately, of course, or there would be deadlock)
>
> I didn't get this impression from other parts of the documentation or
> from a glance at the "pcidrv" sample, but a queue is the only way I
> can think to do this (since a power IRP handler can't block waiting on
> any sort of lock). I thought I saw "pcidrv" doing this bare in a
> state-changing PnP handler, but if state-changing PnP IRPs were really
> mutually exclusive with power IRPs then the documentation shouldn't
> say to hold a remove lock while handling a power IRP (since there
> would be no need for a remove lock during a power IRP if a remove
> couldn't even happen during a power IRP).
>