Okay, what's really up with remove locks?

I got a DDK documentation feedback reply that claimed that
IRP_MN_SET_POWER IRPs are serialized with IRP_MN_REMOVE_DEVICE, which
implies there's no need to grab a remove lock when handling
IRP_MN_SET_POWER, but I thought power IRPs were the least
controversial case. They're actually the only ones mentioned in the
DDK docs in relation to IoAcquireRemoveLock.

If this is true, then when _are_ remove locks ever necessary? I
thought that on 2000 and later, power IRPs and the non-state changing
PnP IRPs were the only IRPs that were supposed to (barring paranoia)
really need them. Are all power IRPs safe or just IRP_MN_SET_POWER?
What about the PnP ones?

Can something be published (outside of this newsgroup) that gives an
authoritative answer on serialization of device removal?

Doron
Mon Jan 01 00:27:49 CST 2007

IRP_MN_SET_POWER/SystemPowerState is the only power irp synchronized with
pnp state. IRP_MN_SET_POWER/DevicePowerState or IRP_MN_WAIT_WAKE are not.
The same clue that I gave for PnP irps applies to power irps, if a driver
can send them (via PoRequestPowerIrp), they are not synchronized with PnP
state. If you are the power policy owner (PPO) for the stack, you really
don't need a remlock for power irps b/c you will control when power irps
arrive. If you are not the PPO (e.g a PDO or a filter), then you should use
a remlock b/c you can't control when power irps will arrive wrt PnP state

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:dp7hp2hp1kfkut3fa6qlqii2503ecbhha1@4ax.com...
>I got a DDK documentation feedback reply that claimed that
> IRP_MN_SET_POWER IRPs are serialized with IRP_MN_REMOVE_DEVICE, which
> implies there's no need to grab a remove lock when handling
> IRP_MN_SET_POWER, but I thought power IRPs were the least
> controversial case. They're actually the only ones mentioned in the
> DDK docs in relation to IoAcquireRemoveLock.
>
> If this is true, then when _are_ remove locks ever necessary? I
> thought that on 2000 and later, power IRPs and the non-state changing
> PnP IRPs were the only IRPs that were supposed to (barring paranoia)
> really need them. Are all power IRPs safe or just IRP_MN_SET_POWER?
> What about the PnP ones?
>
> Can something be published (outside of this newsgroup) that gives an
> authoritative answer on serialization of device removal?
>

BubbaGump
Mon Jan 01 10:23:44 CST 2007

The inconsistency bothers me a little, but that answers my question.
Thanks.




On Sun, 31 Dec 2006 22:27:49 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>IRP_MN_SET_POWER/SystemPowerState is the only power irp synchronized with
>pnp state. IRP_MN_SET_POWER/DevicePowerState or IRP_MN_WAIT_WAKE are not.
>The same clue that I gave for PnP irps applies to power irps, if a driver
>can send them (via PoRequestPowerIrp), they are not synchronized with PnP
>state. If you are the power policy owner (PPO) for the stack, you really
>don't need a remlock for power irps b/c you will control when power irps
>arrive. If you are not the PPO (e.g a PDO or a filter), then you should use
>a remlock b/c you can't control when power irps will arrive wrt PnP state
>
>d

BubbaGump
Mon Jan 01 10:31:08 CST 2007

What about IRP_MN_QUERY_POWER/SystemPowerState?




On Sun, 31 Dec 2006 22:27:49 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>IRP_MN_SET_POWER/SystemPowerState is the only power irp synchronized with
>pnp state. IRP_MN_SET_POWER/DevicePowerState or IRP_MN_WAIT_WAKE are not.
>The same clue that I gave for PnP irps applies to power irps, if a driver
>can send them (via PoRequestPowerIrp), they are not synchronized with PnP
>state. If you are the power policy owner (PPO) for the stack, you really
>don't need a remlock for power irps b/c you will control when power irps
>arrive. If you are not the PPO (e.g a PDO or a filter), then you should use
>a remlock b/c you can't control when power irps will arrive wrt PnP state
>
>d

Doron
Mon Jan 01 12:47:07 CST 2007

nope..and I know this first hand since I thought it was synchronized during
KMDF development and had to change the design after we found out it was not
synchronized with pnp state.

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:1odip257ckhp60ob37pf2i244jfdku5d9h@4ax.com...
> What about IRP_MN_QUERY_POWER/SystemPowerState?
>
>
>
>
> On Sun, 31 Dec 2006 22:27:49 -0800, "Doron Holan [MS]"
> <doronh@nospam.microsoft.com> wrote:
>
>>IRP_MN_SET_POWER/SystemPowerState is the only power irp synchronized with
>>pnp state. IRP_MN_SET_POWER/DevicePowerState or IRP_MN_WAIT_WAKE are not.
>>The same clue that I gave for PnP irps applies to power irps, if a driver
>>can send them (via PoRequestPowerIrp), they are not synchronized with PnP
>>state. If you are the power policy owner (PPO) for the stack, you really
>>don't need a remlock for power irps b/c you will control when power irps
>>arrive. If you are not the PPO (e.g a PDO or a filter), then you should
>>use
>>a remlock b/c you can't control when power irps will arrive wrt PnP state
>>
>>d
>

BubbaGump
Mon Jan 01 17:22:55 CST 2007

We have common enemies.




On Mon, 1 Jan 2007 10:47:07 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:

>nope..and I know this first hand since I thought it was synchronized during
>KMDF development and had to change the design after we found out it was not
>synchronized with pnp state.
>
>d

Don
Mon Jan 01 17:36:47 CST 2007

There is one big difference, Doron and company fought the enemy to provide
a safe path for the rest of us with KMDF, You seem to go to the enemy for
your own entertainment.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



<BubbaGump> wrote in message
news:8p5jp21qvjaecclng420vp88vngratl305@4ax.com...
> We have common enemies.
>
>
>
>
> On Mon, 1 Jan 2007 10:47:07 -0800, "Doron Holan [MS]"
> <doronh@nospam.microsoft.com> wrote:
>
>>nope..and I know this first hand since I thought it was synchronized
>>during
>>KMDF development and had to change the design after we found out it was
>>not
>>synchronized with pnp state.
>>
>>d
>

Maxim
Mon Jan 01 18:59:33 CST 2007

> If this is true, then when _are_ remove locks ever necessary?

Imagine Driver A above Driver B in the devnode. Now imagine Driver A to
initiate some operations - sending its own IRPs down, setting timers,
scheduling work items and DPCs.

The remove lock must be acquired in all these paths, and released when the
initiated operation is complete. So, the remove IRP will be stalled till all of
this will complete.

I think this nearly (if not 100%) only need in remove locks in modern Windows.

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

BubbaGump
Tue Jan 02 17:10:17 CST 2007

I can't verify the first part. I haven't seen KMDF yet to know what
faults I might find in it. I might check it out at some future time
when it becomes more popular.

The second part is true.




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

BubbaGump
Tue Jan 02 17:38:59 CST 2007

On Tue, 2 Jan 2007 03:59:33 +0300, "Maxim S. Shatskih"
<maxim@storagecraft.com> wrote:

>> If this is true, then when _are_ remove locks ever necessary?
>
>Imagine Driver A above Driver B in the devnode. Now imagine Driver A to
>initiate some operations - sending its own IRPs down, setting timers,
>scheduling work items and DPCs.
>
>The remove lock must be acquired in all these paths, and released when the
>initiated operation is complete. So, the remove IRP will be stalled till all of
>this will complete.
>
>I think this nearly (if not 100%) only need in remove locks in modern Windows.

I agree that in an ideal design a driver _should_ only need a remove
lock for operations it initiates, but I see this distorted in WDM.
Look at received IRPs like IRP_MN_SET_POWER/SystemPowerState and
IRP_MN_QUERY_POWER/SystemPowerState. One is synchronized with
removal, and the other isn't.

BubbaGump
Tue Jan 02 17:58:44 CST 2007

If you want, any time I complain about WDM in the future, you can
point out whether the thing I'm complaining about has been made
obsolete in KMDF. That will encourage me to use KMDF.




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

BubbaGump
Tue Jan 02 18:41:50 CST 2007

It's not as much for entertainment as you think. It's meant to
discourage future designs from ever repeating the same mistakes.
You're right in noticing I don't have the patience to inspire some
group of people into following some grand new religion. I'm more
inclined to be a dirty prophet yelling on a street corner than a
priest in white robes. Don't think that's supposed to imply anything
about which one is right or wrong. I'm only differentiating methods.




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

BubbaGump
Tue Jan 02 19:07:27 CST 2007

Also, I don't know why by now, but it never ceases to amaze me how
often I run into ***holes who enjoy criticizing me. I may criticize
more than most, but it's usually towards an abstract concept or a
group of people and only an individual when that person is directly
attacking me. What the hell. I make a complaint about a book, and an
***hole criticizes me. I ask a question, and an ***hole criticizes
me. I try to find common ground (the enemy of my enemy is my friend),
and an ***hole criticizes me.

I said nothing against you, unless you consider WDM some sort of
extension of yourself.

(I wasn't sure if this group is supposed to be censored, so you can
read "***hole" as "eyehole")




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

Doron
Tue Jan 02 21:17:07 CST 2007

OK. Almost every single thing you have asked about so far has been taken
care of for you in KMDF. I told you this when you first started posting, it
is worth repeating now. Alot of the gotchas you see in WDM are dealt with
by KMDF

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:o8slp2dbsv4tnre676dtk5b5cqh4koli8k@4ax.com...
> If you want, any time I complain about WDM in the future, you can
> point out whether the thing I'm complaining about has been made
> obsolete in KMDF. That will encourage me to use KMDF.
>
>
>
>
> On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
> wrote:
>
>>There is one big difference, Doron and company fought the enemy to provide
>>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>>your own entertainment.
>

Don
Wed Jan 03 07:24:46 CST 2007

No it is purely entertainment and mostly for yourself since it has come to
the point when a lot of us see there are postings on this group, we assume
it is you!

I have been part of the architecture team of a number of system software
level products including some operating systems, and you never tackle this
level of detail when doing the initial design, because either you look at
the big picture of what is good and bad with a system, or you decide you
need compatibility with the system and cannot change the messy details.

If you wanted to start a discussion on what the PnP model does well and
what it does poorly, and approaches other systems have used to solve
similar problems, this would be interesting, though probably this is not
the appropriate group.

As it is, you remind me of a co-worker who management thought was
outstanding back on one of the first OS'es I helped design. The guy got so
hung up on details, when the design team was still at a high level that he
disrupted every design session we had. Management thought his detail
orientation would help make sure the design was good, and kept him on as
the project slipped and slipped due to his wanting details on strawman
designs! The rest of the design team finally forced his demotion to
programmer where he still was worthless, because he could not code anything
till he understood in perfect detail everything (including stuff he was not
implementing or using). In the end he was terminated from the company with
a bad enough reputation he never worked in the industry again.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



<BubbaGump> wrote in message
news:0julp2tfm0mrqi2f2je4q6qbftjavnb2lq@4ax.com...
> It's not as much for entertainment as you think. It's meant to
> discourage future designs from ever repeating the same mistakes.
> You're right in noticing I don't have the patience to inspire some
> group of people into following some grand new religion. I'm more
> inclined to be a dirty prophet yelling on a street corner than a
> priest in white robes. Don't think that's supposed to imply anything
> about which one is right or wrong. I'm only differentiating methods.
>
>
>
>
> On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
> wrote:
>
>>There is one big difference, Doron and company fought the enemy to
>>provide
>>a safe path for the rest of us with KMDF, You seem to go to the enemy
>>for
>>your own entertainment.
>

BubbaGump
Wed Jan 03 09:42:00 CST 2007

On the word "entertainment", that is the reason anyone ever does
anything. There is no such thing as a noble action. People gain high
positions in big companies for their own entertainment. People
express their opinions for their own entertainment. I guess you just
prefer the one that entertains you too.

On effectiveness, I don't have the patience for or the understanding
of political games. I also don't believe in motivating people by
giving them some exalted leader to worship. I think people should
think on their own.

If some person in charge gave me access to the WDM source and the WDM
documentation then maybe I'd change them, but there's a mountain of
politics in the way.




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

BubbaGump
Wed Jan 03 14:16:00 CST 2007

More to the point, my war is ideological. I don't try to change the
way people act. I try to offer them a new way to think.

It's politics vs. philosophy.

What good is philosophy? Well, what good is politics? This will all
be dust or at the bottom of the ocean in a thousand years.




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

BubbaGump
Wed Jan 03 18:29:01 CST 2007

By the way, doesn't KMDF just layer over top of WDM? That's not
fighting the enemy. That's hiding the enemy's existence. Fighting
the enemy would involve first fixing the parts of WDM that are poorly
designed yet wouldn't break current drivers.

Also, who's "and company"? I hope you mean other
corporate-ladder-climbing politicians. You couldn't mean software
developers. All software developers do is wait around for some
politician who happens to work at their company to give them a project
to work on, KMDF or WXY or whatever. They don't do anything special.

If you could keep your comments from being personal, these discussions
would be a lot shorter and more technically focused. Pure technical
discussions are my favorite. Philosophical debates are interesting
when I'm really bored, although they being to wear on me after a
while, but personal arguments just annoy me.

By "personal" I mean you trying to judge the validity of what I say.
Are you a Republican? You dismiss my protests like Ann Coulter
dismissing all liberals on a 24-hour news network. Of course, I am
godless. :-)




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

Don
Wed Jan 03 19:10:04 CST 2007


<BubbaGump> wrote in message
news:qahop21klfbfr1s160ghpe6jruec8m9rvc@4ax.com...
> By the way, doesn't KMDF just layer over top of WDM? That's not
> fighting the enemy. That's hiding the enemy's existence. Fighting
> the enemy would involve first fixing the parts of WDM that are poorly
> designed yet wouldn't break current drivers.

And if you cannot fix WDM since it would break many of the 100,000 drivers
out there what would you do? Also, if most drivers are incorrect because
the complexity of the state machine, is it valid to provide a wrapper with
a state machine that handles the complexity? KMDF was a multi-year effort
with a lot of input by the community on how to improve the driver writing
experience

> Also, who's "and company"? I hope you mean other
> corporate-ladder-climbing politicians. You couldn't mean software
> developers. All software developers do is wait around for some
> politician who happens to work at their company to give them a project
> to work on, KMDF or WXY or whatever. They don't do anything special.

Obviously, you have not worked at a high level in a decent company. Plenty
of projects are instigated by software developers, not by management. I
can name half a dozen products that shipped because I suggested and/or
fought for them, let alone a number of experiments and prototypes. If you
really think that all this stuff comes down from the top and a "good
developer" doesn't do anything special, it shows you are likely to be a low
level drone at best.

> If you could keep your comments from being personal, these discussions
> would be a lot shorter and more technically focused. Pure technical
> discussions are my favorite. Philosophical debates are interesting
> when I'm really bored, although they being to wear on me after a
> while, but personal arguments just annoy me.

But the crap you are spewing is almost totally philosophy!!! You are
asking for details any working developer does not concern themselves with,
but which you claim are essential. You are digging into a driver level,
that most practical programmers are thankful they no longer have to deal
with since they can use KDMF. But you refuse to go top down and instead
want people to answer every little detail to your satisfaction, while along
the way criticizing the design, without understanding the history that
caused it to come about.

Personally, I've tried to ignore you for the most part, but you are taking
most of the bandwidth of this group, with riduculous questions and FUD
about how badly WDM is designed. Please do everyone a favor and go over to
Linux.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

BubbaGump
Wed Jan 03 19:17:04 CST 2007

What you say below seems to say you wish you had been Doron and worked
on KMDF, but how does telling me that I should have been Doron and
worked on KMDF help you do that? (which first would require the
improbable feat of both of us getting jobs in the right department at
Microsoft) Personally, I like being me, and I'm sure Doron likes
being Doron, but if you think being Doron is better than being me,
then why don't you be more like Doron and only respond with helpful
technical information instead of insulting comments? A more helpful
response would have been a comparison of power management removal
synchronization between WDM and KMDF.




On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
wrote:

>There is one big difference, Doron and company fought the enemy to provide
>a safe path for the rest of us with KMDF, You seem to go to the enemy for
>your own entertainment.

Don
Wed Jan 03 19:25:35 CST 2007

I respect Doron and the other members of the KDMF, many of whom I am
fortunate enought to have met. But personally, I have no wish to be
directly employed by a big company like Microsoft again. Since you refuse
to read about KMDF until you have learned every tiny nuance of WDM, trying
to describe the difference would be useless.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply




<BubbaGump> wrote in message
news:hqkop2lksftqvoc99k9ko04g86rocvpqtn@4ax.com...
> What you say below seems to say you wish you had been Doron and worked
> on KMDF, but how does telling me that I should have been Doron and
> worked on KMDF help you do that? (which first would require the
> improbable feat of both of us getting jobs in the right department at
> Microsoft) Personally, I like being me, and I'm sure Doron likes
> being Doron, but if you think being Doron is better than being me,
> then why don't you be more like Doron and only respond with helpful
> technical information instead of insulting comments? A more helpful
> response would have been a comparison of power management removal
> synchronization between WDM and KMDF.
>
>
>
>
> On Mon, 1 Jan 2007 18:36:47 -0500, "Don Burn" <burn@stopspam.acm.org>
> wrote:
>
>>There is one big difference, Doron and company fought the enemy to
>>provide
>>a safe path for the rest of us with KMDF, You seem to go to the enemy
>>for
>>your own entertainment.
>