A sort of "query remove lock"?
in [Device Drivers]
|
From: BubbaGump on 6 Oct 2006 17:48 Of course, if there was such a reverse release request mechanism then an outstanding interface reference would never be a need to fail a IRP_MN_QUERY_REMOVE_DEVICE as the documentation suggests. The idea of anything being able to prevent a voluntary remove conflicts with the idea of nothing being able to prevent a surprise remove, unless the system is expected to behave unpredictably after a surprise remove (but a hot-pluggable bus should be resilient enough hardware-wise, so it'd be nice if its drivers were resilient software-wise). On Fri, 06 Oct 2006 13:35:24 -0400, BubbaGump <> wrote: >...forever...unless there's some way to notify whoever has references >to the interface to please release it? > > > > >On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote: > >>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That >>must be held forever until the interface is released, since it might >>allow the unload of the code and data to which the interface refers. >> >> >> >> >>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org> >>wrote: >> >>>It can fail all the requests to the interface currently in progress and >>>issued in the future, it can not hold the SURPRISE_REMOVAL forever.
From: Alexander Grigoriev on 6 Oct 2006 23:45 If an upper driver holds an interface reference, it should release those when it receives REMOVE_DEVICE. If a device from PDO stack hold an interface to FDO, FDO will be around until all PDO stacks are gone. Af a third driver holds an interface reference, it's a good idea if it also held a FILE_OBJECT to the target device. This also allows to register for query remove request. <BubbaGump> wrote in message news:ls4di2hul4m63hq736pvcoh179llrat0hk(a)4ax.com... > ...forever...unless there's some way to notify whoever has references > to the interface to please release it? > > > > > On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote: > >>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That >>must be held forever until the interface is released, since it might >>allow the unload of the code and data to which the interface refers. >> >> >> >> >>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org> >>wrote: >> >>>It can fail all the requests to the interface currently in progress and >>>issued in the future, it can not hold the SURPRISE_REMOVAL forever. >
From: BubbaGump on 7 Oct 2006 08:20 That first case (upper holding interface reference of lower) sounds fine. That second case (lower holding interface reference of upper) sounds fine, but the ordering might be important. I almost thought it was deadlock. In PnP remove the upper should cause all requests on the interface to fail in order to cease activity, forward the remove IRP, then wait for the interface to be released. The forward should cause the lower to release the interface so the wait won't take forever. That third case sounds fine too. I forgot about PnP notification. Thanks. On Fri, 6 Oct 2006 20:45:29 -0700, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >If an upper driver holds an interface reference, it should release those >when it receives REMOVE_DEVICE. If a device from PDO stack hold an interface >to FDO, FDO will be around until all PDO stacks are gone. >Af a third driver holds an interface reference, it's a good idea if it also >held a FILE_OBJECT to the target device. This also allows to register for >query remove request. > ><BubbaGump> wrote in message >news:ls4di2hul4m63hq736pvcoh179llrat0hk(a)4ax.com... >> ...forever...unless there's some way to notify whoever has references >> to the interface to please release it? >> >> >> >> >> On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote: >> >>>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That >>>must be held forever until the interface is released, since it might >>>allow the unload of the code and data to which the interface refers. >>> >>> >>> >>> >>>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org> >>>wrote: >>> >>>>It can fail all the requests to the interface currently in progress and >>>>issued in the future, it can not hold the SURPRISE_REMOVAL forever. >> >
From: Alexander Grigoriev on 7 Oct 2006 13:18 Second case is also upper (child PDO) to lower (parent FDO). <BubbaGump> wrote in message news:vr5fi29g8uv5cr6iipbket35gbpgc007o4(a)4ax.com... > That first case (upper holding interface reference of lower) sounds > fine. > > That second case (lower holding interface reference of upper) sounds > fine, but the ordering might be important. I almost thought it was > deadlock. In PnP remove the upper should cause all requests on the > interface to fail in order to cease activity, forward the remove IRP, > then wait for the interface to be released. The forward should cause > the lower to release the interface so the wait won't take forever. > > That third case sounds fine too. I forgot about PnP notification. > Thanks. > > > > > On Fri, 6 Oct 2006 20:45:29 -0700, "Alexander Grigoriev" > <alegr(a)earthlink.net> wrote: > >>If an upper driver holds an interface reference, it should release those >>when it receives REMOVE_DEVICE. If a device from PDO stack hold an >>interface >>to FDO, FDO will be around until all PDO stacks are gone. >>Af a third driver holds an interface reference, it's a good idea if it >>also >>held a FILE_OBJECT to the target device. This also allows to register for >>query remove request. >> >><BubbaGump> wrote in message >>news:ls4di2hul4m63hq736pvcoh179llrat0hk(a)4ax.com... >>> ...forever...unless there's some way to notify whoever has references >>> to the interface to please release it? >>> >>> >>> >>> >>> On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote: >>> >>>>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That >>>>must be held forever until the interface is released, since it might >>>>allow the unload of the code and data to which the interface refers. >>>> >>>> >>>> >>>> >>>>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org> >>>>wrote: >>>> >>>>>It can fail all the requests to the interface currently in progress and >>>>>issued in the future, it can not hold the SURPRISE_REMOVAL forever. >>> >> >
From: BubbaGump on 7 Oct 2006 14:50 I didn't realize you actually meant child PDO, but a child PDO and a parent FDO are controlled by the same driver so that driver should be able to coordinate the release of any of its resources internally, and this case shouldn't be an issue. I was concerned about what mechanism(s) a driver could use to notify another driver that removal was happening. (By the way, the "Removing a Device in a Function Driver" page in the DDK actually says the order in which child PDOs and the parent FDO receive remove IRPs can be either child first or parent first. Apparently a surprise remove on a child stack might end up causing a parent stack to receive its remove first.) Anyway, I was thinking, your suggestion of each driver that holds an interface also holding a file handle and using PnP query/remove notification is the least error prone and most general solution for any of the cases. The driver shouldn't need to know where it is if it does this. On Sat, 7 Oct 2006 10:18:02 -0700, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >Second case is also upper (child PDO) to lower (parent FDO). > ><BubbaGump> wrote in message >news:vr5fi29g8uv5cr6iipbket35gbpgc007o4(a)4ax.com... >> That first case (upper holding interface reference of lower) sounds >> fine. >> >> That second case (lower holding interface reference of upper) sounds >> fine, but the ordering might be important. I almost thought it was >> deadlock. In PnP remove the upper should cause all requests on the >> interface to fail in order to cease activity, forward the remove IRP, >> then wait for the interface to be released. The forward should cause >> the lower to release the interface so the wait won't take forever. >> >> That third case sounds fine too. I forgot about PnP notification. >> Thanks. >> >> >> >> >> On Fri, 6 Oct 2006 20:45:29 -0700, "Alexander Grigoriev" >> <alegr(a)earthlink.net> wrote: >> >>>If an upper driver holds an interface reference, it should release those >>>when it receives REMOVE_DEVICE. If a device from PDO stack hold an >>>interface >>>to FDO, FDO will be around until all PDO stacks are gone. >>>Af a third driver holds an interface reference, it's a good idea if it >>>also >>>held a FILE_OBJECT to the target device. This also allows to register for >>>query remove request. >>> >>><BubbaGump> wrote in message >>>news:ls4di2hul4m63hq736pvcoh179llrat0hk(a)4ax.com... >>>> ...forever...unless there's some way to notify whoever has references >>>> to the interface to please release it? >>>> >>>> >>>> >>>> >>>> On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote: >>>> >>>>>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That >>>>>must be held forever until the interface is released, since it might >>>>>allow the unload of the code and data to which the interface refers. >>>>> >>>>> >>>>> >>>>> >>>>>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org> >>>>>wrote: >>>>> >>>>>>It can fail all the requests to the interface currently in progress and >>>>>>issued in the future, it can not hold the SURPRISE_REMOVAL forever. >>>> >>> >> >
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: nonPNP sample driver won't install when running .exe Next: wdk Vista mirror driver |