File Object Lock with WDK
in [Device Drivers]
|
Prev: American E-commerce Increasingly Outside the Legal Positions
Next: How to get device key (hardware key) path in kernel mode ?
From: Asaf Shelly on 27 Aug 2010 01:18 > OK, so the problem is that some app can wait on the real COM port, > and then you cannot send the special ioctl because you cannot open > another handle to the device, because it is exclusive. > > Various solutions are possible here, and can be done in WDM or KMDF, > but I cannot agree that KMDF can change anything in this situation; it is > just a wrapper around bare OS (a.k.a. WDM). > The problem I am having is that the synchronization is done by the KMDF engine. Serial is always blocking reads but what if someone is using a driver, for example a disk driver, which is not blocking unless the queue is full? The problem I am seeing will appear only at deployment. Bad timing for a driver redesing. Asaf
From: Pavel A. on 27 Aug 2010 11:30 "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message news:64DD3C0C-198B-4AAA-8709-6AF44AC27C64(a)microsoft.com... >> OK, so the problem is that some app can wait on the real COM port, >> and then you cannot send the special ioctl because you cannot open >> another handle to the device, because it is exclusive. >> >> Various solutions are possible here, and can be done in WDM or KMDF, >> but I cannot agree that KMDF can change anything in this situation; it is >> just a wrapper around bare OS (a.k.a. WDM). >> > > > The problem I am having is that the synchronization is done by the KMDF > engine. > Serial is always blocking reads but what if someone is using a driver, for > example a disk driver, which is not blocking unless the queue is full? The > problem I am seeing will appear only at deployment. Bad timing for a > driver > redesing. > > Asaf KMDF (and the win. kernel) also are around for quite long. Not a good time to redesign these as well... Why you cannot kill the app holding on the com port as Maxim suggested? -- pa
From: Asaf Shelly on 28 Aug 2010 18:00 > KMDF (and the win. kernel) also are around for quite long. Not a good time > to redesign these as well... > > Why you cannot kill the app holding on the com port as Maxim suggested? Because it is wrong to ask the user to close an application with penalty of entire system not responding. What if my driver is managing a global resource? Can you imagine having to ask the users to locate an close the Bluetooth application which is making my driver irresponsive? Until you find that service you cannot access any Bluetooth functionality because the driver is locked... Asaf
From: Pavel A. on 28 Aug 2010 18:49 "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message news:90C502F3-BFE4-45E7-A8B1-0CA1777635D0(a)microsoft.com... >> KMDF (and the win. kernel) also are around for quite long. Not a good >> time >> to redesign these as well... >> >> Why you cannot kill the app holding on the com port as Maxim suggested? > > Because it is wrong to ask the user to close an application with penalty > of > entire system not responding. > What if my driver is managing a global resource? Can you imagine having to > ask the users to locate an close the Bluetooth application which is making > my > driver irresponsive? Until you find that service you cannot access any > Bluetooth functionality because the driver is locked... > > Asaf I *can* imagine asking the user to reboot. Users know that Windows likes reboots ;) --pa
From: Maxim S. Shatskih on 29 Aug 2010 09:06
> Serial is always blocking reads but what if someone is using a driver, for > example a disk driver, which is not blocking unless the queue is full? Disk stack is never ever blocking. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com |