Re: IRP_MN_QUERY_DEVICE_RELATIONS concurrency
- From: "Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 25 Dec 2006 09:41:13 -0800
usage notifications are usually sent during the start path. note that other
irps that could lead to a query remove failure (like create, query
interface) are not syncronized with pnp state changing irps either. the key
here is if another driver is allowed to send the pnp minor irp, it is not
synchronized with any pnp state changing irp.
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:viguo25caqedjmb9lolj89kgi96okk5usc@xxxxxxxxxx
On Sun, 24 Dec 2006 16:57:32 -0800, Tim Roberts <timr@xxxxxxxxx>
wrote:
BubbaGump <> wrote:
Okay, handling everything one at a time would hurt concurrency a bit
(although I'm still trying to imagine what PnP operation might wait on
something for so long that it would be noticeable).
Anyway, I thought you might mention that BusRelations is already
serialized. You alluded to it the other day, but another IRP I would
have expected to be serialized with all these is
IRP_MN_DEVICE_USAGE_NOTIFICATION, and I think I heard a while ago that
it's not.
That IRP doesn't change change state, so serialization isn't particularly
important. It's a query only. In addition, that IRP only applies to
drivers for devices that can contain a paging file, a dump file, or a
hibernation file. That's a very narrow class of drivers.
IRP_MN_DEVICE_USAGE_NOTIFICATION does change state because being used
for a paging file, a dump file, or a hibernation file is state that
must be taken into account by IRP_MN_QUERY_REMOVE_DEVICE. If a device
is being used for one of those things, then IRP_MN_QUERY_REMOVE_DEVICE
should fail and not allow PnP state to change to remove-pending. If
PnP state is already remove-pending, then
IRP_MN_DEVICE_USAGE_NOTIFICATION should fail and not allow the device
to be used for one of those things. It's not just a query. It's a
query and a change of state (a test-and-set) from both perspectives.
Serialization is important to avoid a race and prevent device usage
from co-existing with a conflicting PnP state.
I suppose it only applies to storage drivers and all other drivers
would just fail IRP_MN_DEVICE_USAGE_NOTIFICATION, but if the location
in the OS that sends IRP_MN_DEVICE_USAGE_NOTIFICATION was common for
all drivers then serializing it would help the drivers that use it
without hurting the ones that don't. If the OS doesn't serialize and
the driver has to, then I agree that drivers that don't support it
should be able to just fail it without doing anything else.
.
- References:
- Re: IRP_MN_QUERY_DEVICE_RELATIONS concurrency
- From: Doron Holan [MS]
- Re: IRP_MN_QUERY_DEVICE_RELATIONS concurrency
- From: Tim Roberts
- Re: IRP_MN_QUERY_DEVICE_RELATIONS concurrency
- Prev by Date: Is there a api/call to print stack trace to windbg from within my driver?
- Next by Date: Re: The issue of Driver install with the application coinstall on Vist
- Previous by thread: Re: IRP_MN_QUERY_DEVICE_RELATIONS concurrency
- Next by thread: Re: IRP_MN_QUERY_DEVICE_RELATIONS concurrency
- Index(es):
Relevant Pages
|