Stall flag vs. remove lock

I've been looking at the WDM book queueing example and it seems there
are two similar methods for making sure driver activity has ceased
before removing a device:

stallcount/WaitForCurrentIrp()

and:


IoAcquireRemoveLock()/IoReleaseRemoveLock()/IoReleaseRemoveLockAndWait()

The idea behind the first method is to prevent any new device I/O from
being initiated and wait for the current I/O to finish.

The idea behind the second method is to prevent any new IRPs from
being forwarded to a lower driver and wait for the current IRPs
forwarded to a lower driver to complete (so that the driver can't
finish the next IRP_MN_REMOVE_DEVICE it might receive until those IRPs
are completed).

The ideas are very similar. They both center around whether some
operation is in progress, whether the device is "busy". It seems like
with some code changes, a single method would work, one that simply
controls whether the device is currently busy and/or in the process of
removal and can wait until the device is no longer busy.

Doron
Fri Sep 08 01:01:09 CDT 2006

yes and no. you will want to be able to queue i/o independent of pnp state.
let's stay you want to prevent i/o from being processed while you reset the
device. so, what you do is build up queue functionality so that you have
functions like stop/purge/restart. on remove device, you synchronously
purge all the queues. this gets you only so far.

for the remaining pirp that might come into your driver (power, wmi, etc)
you use a remlock. the remlock is not necessarily to track i/o that you fwd
down the stack. rather it is for tracking any i/o currently in the driver
or being processed by the driver (which includes sending it somewhere else
and processing it in a completion routine).

KMDF does all this for you if you care (which i think you don't) and let's
you focus on innovating where it counts, in the logic of the driver itself

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<BubbaGump> wrote in message
news:v6b1g2h9ethnq5ujucle2eag3ghofafn6t@4ax.com...
> I've been looking at the WDM book queueing example and it seems there
> are two similar methods for making sure driver activity has ceased
> before removing a device:
>
> stallcount/WaitForCurrentIrp()
>
> and:
>
>
> IoAcquireRemoveLock()/IoReleaseRemoveLock()/IoReleaseRemoveLockAndWait()
>
> The idea behind the first method is to prevent any new device I/O from
> being initiated and wait for the current I/O to finish.
>
> The idea behind the second method is to prevent any new IRPs from
> being forwarded to a lower driver and wait for the current IRPs
> forwarded to a lower driver to complete (so that the driver can't
> finish the next IRP_MN_REMOVE_DEVICE it might receive until those IRPs
> are completed).
>
> The ideas are very similar. They both center around whether some
> operation is in progress, whether the device is "busy". It seems like
> with some code changes, a single method would work, one that simply
> controls whether the device is currently busy and/or in the process of
> removal and can wait until the device is no longer busy.
>

BubbaGump
Thu Sep 14 12:12:46 CDT 2006

On Thu, 7 Sep 2006 23:01:09 -0700, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>KMDF does all this for you if you care (which i think you don't) and let's
>you focus on innovating where it counts, in the logic of the driver itself

I do care. I just go to extremes, all or nothing. I want to see all
of this in WDM, but I look forward to seeing none of it in KMDF.

BubbaGump
Thu Sep 14 12:18:21 CDT 2006

On Thu, 7 Sep 2006 23:01:09 -0700, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>yes and no. you will want to be able to queue i/o independent of pnp state.
>let's stay you want to prevent i/o from being processed while you reset the
>device. so, what you do is build up queue functionality so that you have
>functions like stop/purge/restart. on remove device, you synchronously
>purge all the queues. this gets you only so far.

Okay, so it sounds like stop is geared towards halting the physical
part of the device (blurring the word "physical" for devices that have
no real hardware), while it sounds like remove is geared towards
halting all operations.


>for the remaining pirp that might come into your driver (power, wmi, etc)
>you use a remlock. the remlock is not necessarily to track i/o that you fwd
>down the stack. rather it is for tracking any i/o currently in the driver
>or being processed by the driver (which includes sending it somewhere else
>and processing it in a completion routine).

In some odd cases in the WDM book, it sounds like it's necessary for
the forwarded ones too.

BubbaGump
Thu Sep 14 12:29:08 CDT 2006

On Thu, 14 Sep 2006 13:12:56 -0400, BubbaGump <> wrote:

>On Thu, 7 Sep 2006 23:01:09 -0700, "Doron Holan [MS]"
><doronh@nospam.microsoft.com> wrote:
>
>>KMDF does all this for you if you care (which i think you don't) and let's
>>you focus on innovating where it counts, in the logic of the driver itself
>
>I do care. I just go to extremes, all or nothing. I want to see all
>of this in WDM, but I look forward to seeing none of it in KMDF.

I shouldn't have said that. I forgot I was sick of debating
philosophy at the moment.

Maxim
Thu Sep 14 12:40:34 CDT 2006

> Okay, so it sounds like stop is geared towards halting the physical
> part of the device (blurring the word "physical" for devices that have
> no real hardware), while it sounds like remove is geared towards
> halting all operations.

Stop is for resource rebalancing only. Yes, during the stop states, the
hardware must not be touched and the IRPs must be collected to the queue.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

BubbaGump
Thu Sep 14 12:56:17 CDT 2006

On Thu, 14 Sep 2006 13:29:18 -0400, BubbaGump <> wrote:

>On Thu, 14 Sep 2006 13:12:56 -0400, BubbaGump <> wrote:
>
>>On Thu, 7 Sep 2006 23:01:09 -0700, "Doron Holan [MS]"
>><doronh@nospam.microsoft.com> wrote:
>>
>>>KMDF does all this for you if you care (which i think you don't) and let's
>>>you focus on innovating where it counts, in the logic of the driver itself
>>
>>I do care. I just go to extremes, all or nothing. I want to see all
>>of this in WDM, but I look forward to seeing none of it in KMDF.
>
>I shouldn't have said that. I forgot I was sick of debating
>philosophy at the moment.

(I know I start arguments, but after a while I get bored with them and
want to do something new)

BubbaGump
Thu Sep 14 13:00:28 CDT 2006

On Thu, 14 Sep 2006 21:40:34 +0400, "Maxim S. Shatskih"
<maxim@storagecraft.com> wrote:

>> Okay, so it sounds like stop is geared towards halting the physical
>> part of the device (blurring the word "physical" for devices that have
>> no real hardware), while it sounds like remove is geared towards
>> halting all operations.
>
>Stop is for resource rebalancing only. Yes, during the stop states, the
>hardware must not be touched and the IRPs must be collected to the queue.

Do devices that use no physical resources have to do anything in stop?
For instance, would some hypothetical ram disk driver that does all
its I/O to some buffer in memory still have to stall its IRP queues on
a stop?

BubbaGump
Thu Sep 14 13:13:04 CDT 2006

On Thu, 14 Sep 2006 14:00:38 -0400, BubbaGump <> wrote:

>On Thu, 14 Sep 2006 21:40:34 +0400, "Maxim S. Shatskih"
><maxim@storagecraft.com> wrote:
>
>>> Okay, so it sounds like stop is geared towards halting the physical
>>> part of the device (blurring the word "physical" for devices that have
>>> no real hardware), while it sounds like remove is geared towards
>>> halting all operations.
>>
>>Stop is for resource rebalancing only. Yes, during the stop states, the
>>hardware must not be touched and the IRPs must be collected to the queue.
>
>Do devices that use no physical resources have to do anything in stop?
>For instance, would some hypothetical ram disk driver that does all
>its I/O to some buffer in memory still have to stall its IRP queues on
>a stop?

Of course, the idea of having IRP queues in that example is a little
inappropriate since I/O's from a buffer in memory can be completed
immediately and don't need to be queued, but still I'm curious if a
driver in that position would ever have to really stop completing
those I/O's.

BubbaGump
Thu Sep 14 14:40:54 CDT 2006

On Thu, 14 Sep 2006 13:18:31 -0400, BubbaGump <> wrote:

>On Thu, 7 Sep 2006 23:01:09 -0700, "Doron Holan [MS]"
><doronh@nospam.microsoft.com> wrote:
>
>>for the remaining pirp that might come into your driver (power, wmi, etc)
>>you use a remlock. the remlock is not necessarily to track i/o that you fwd
>>down the stack. rather it is for tracking any i/o currently in the driver
>>or being processed by the driver (which includes sending it somewhere else
>>and processing it in a completion routine).
>
>In some odd cases in the WDM book, it sounds like it's necessary for
>the forwarded ones too.

Never mind. This comment of mine is meaningless. I read your post
too quickly and thought you said "not necessary" when you actually
said "not necessarily".

BubbaGump
Thu Sep 14 14:44:07 CDT 2006

On Thu, 7 Sep 2006 23:01:09 -0700, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>for the remaining pirp that might come into your driver (power, wmi, etc)
>you use a remlock. the remlock is not necessarily to track i/o that you fwd
>down the stack. rather it is for tracking any i/o currently in the driver
>or being processed by the driver (which includes sending it somewhere else
>and processing it in a completion routine).

I did use "forward" wrong. I was thinking any I/O. I need to get my
language straight.

Peter
Thu Sep 14 14:54:16 CDT 2006

As long as you can satisfy the request without touching the resources you
were assigned (and in this case there aren't any) you can probably go ahead
and keep running.

-p

"BubbaGump" wrote in message
news:106jg25pnbja9k0c5funu18hem0kcud3f9@4ax.com...
> On Thu, 14 Sep 2006 21:40:34 +0400, "Maxim S. Shatskih"
> <maxim@storagecraft.com> wrote:
>
>>> Okay, so it sounds like stop is geared towards halting the physical
>>> part of the device (blurring the word "physical" for devices that have
>>> no real hardware), while it sounds like remove is geared towards
>>> halting all operations.
>>
>>Stop is for resource rebalancing only. Yes, during the stop states, the
>>hardware must not be touched and the IRPs must be collected to the queue.
>
> Do devices that use no physical resources have to do anything in stop?
> For instance, would some hypothetical ram disk driver that does all
> its I/O to some buffer in memory still have to stall its IRP queues on
> a stop?
>

BubbaGump
Thu Sep 14 15:08:07 CDT 2006

On Thu, 14 Sep 2006 15:44:18 -0400, BubbaGump <> wrote:

>On Thu, 7 Sep 2006 23:01:09 -0700, "Doron Holan [MS]"
><doronh@nospam.microsoft.com> wrote:
>
>>for the remaining pirp that might come into your driver (power, wmi, etc)
>>you use a remlock. the remlock is not necessarily to track i/o that you fwd
>>down the stack. rather it is for tracking any i/o currently in the driver
>>or being processed by the driver (which includes sending it somewhere else
>>and processing it in a completion routine).
>
>I did use "forward" wrong. I was thinking any I/O. I need to get my
>language straight.

Actually, I was originally thinking any non-queued I/O and only
wondering about any I/O. In any case, I think you answered my
original question about why there are two mechanisms, so at some point
I may stop blathering.