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: Pavel A. on 23 Aug 2010 07:30 "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message news:2CEB94A2-FFAA-45B9-93E8-E01FB3AB3ADE(a)microsoft.com... ........... > What I am looking for is not a solution to the problem, I am looking for a > way to isolate the rest of the driver from the 'stupid user'. Not sure if I completely understand this statement, but maybe you need a better interface concept. See http://www.osronline.com/showThread.cfm?link=188211 message #26 "you must never, ever, not even once, think that ReadFile, WriteFile, and/or DeviceIoControl are the *user visible* interfaces to your driver. Do this, and it warps your thinking into trying to make this low-level interface "easy to use". No, decide what you want the upper-level user interface to look like, to the application programmer. Then writer a library that translates that into low-level calls like DeviceIoControl. ... There is a line between the effort we expend in kernel space and the effort we expend in user space to make a piece of hardware work. The user space gets split between what the application writer *has* to see, and what you can write as a library. The smaller the kernel piece, the faster you get it done, the more robust it is likely to be. ............. So you design the API *first*, then figure out how you are going to map it to low-level calls, then figure out how you are going to get the performance you need " ( Joseph Newcomer, co-author of the "Developing Windows NT Device Drivers" book) IMHO, "stupid users" is a misnomer. Our users are not stupid at all ;) Instead, how about "users that don't want to care about boring details" ? They are not going to access low level interfaces at all, exactly because these are encumbered with lot of boring details. These folks should use higher level, more robust interfaces, like message queues, and automatic memory management. Regards, --pa
From: Asaf Shelly on 23 Aug 2010 18:42 Hi Pavel, I understand and agree with you. Here is my scenario: There used to be an old physical box connected to the COM port and managed by it. This box was used to manage a frame based communication bus with accurate timing that applications failed to provide. Some 10 years ago I created a driver which was a replacement for the box. The solution was a filter driver attaching on to the COM port and emulating the external box with all serial commands. This was a good solution becuase there was no need to modify the existing applications using the old box. Today we had the opportumity to redesign the system. In order to allow backward compatibility I allow transparent Read and Write to COM port until a special io control is received. The problem I am seeing today is more of a design concept problem. I don't see a reason why a single application could make my driver not respond to any other application. This can be solved with some work but I would expect KMDF to provide some protection from such mistakes. Eventually there will be some programmer who will not consider this situation and release a driver that can be non responsive to all client applications because the lower level driver is blocking. Asaf "Pavel A." wrote: > "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message > news:2CEB94A2-FFAA-45B9-93E8-E01FB3AB3ADE(a)microsoft.com... > .......... > > What I am looking for is not a solution to the problem, I am looking for a > > way to isolate the rest of the driver from the 'stupid user'. > > Not sure if I completely understand this statement, but maybe you need > a better interface concept. > > See http://www.osronline.com/showThread.cfm?link=188211 > message #26 > > "you must never, ever, not even once, think that ReadFile, WriteFile, and/or > DeviceIoControl > are the *user visible* interfaces to your driver. Do this, and it warps > your thinking > into trying to make this low-level interface "easy to use". No, decide what > you want the upper-level user interface to look like, to the application > programmer. Then writer a library that translates that into low-level calls > like DeviceIoControl. ... > > There is a line between the effort we expend in kernel space and the effort > we expend in user space to make a piece of hardware work. The user space > gets split between what the application writer *has* to see, and what you > can write as a library. The smaller the kernel piece, the faster you get it > done, the more robust it is likely to be. ............. > So you design the API *first*, then figure out how you are going to map it > to > low-level calls, then figure out how you are going to get the performance > you need " > ( Joseph Newcomer, co-author of the "Developing Windows NT Device Drivers" > book) > > IMHO, "stupid users" is a misnomer. Our users are not stupid at all ;) > Instead, how about "users that don't want to care about boring > details" ? > They are not going to access low level interfaces at all, exactly because > these are encumbered with lot of boring details. > These folks should use higher level, more robust interfaces, like message > queues, > and automatic memory management. > > Regards, > --pa > >
From: Pavel A. on 23 Aug 2010 22:55 "Asaf Shelly" <MSMediaForum(a)Shelly.co.il> wrote in message news:C3188274-71C9-48FD-95AA-5D199E5FECF3(a)microsoft.com... > Hi Pavel, > > I understand and agree with you. Here is my scenario: > > There used to be an old physical box connected to the COM port and managed > by it. This box was used to manage a frame based communication bus with > accurate timing that applications failed to provide. Some 10 years ago I > created a driver which was a replacement for the box. The solution was a > filter driver attaching on to the COM port and emulating the external box > with all serial commands. This was a good solution becuase there was no > need > to modify the existing applications using the old box. > Today we had the opportumity to redesign the system. In order to allow > backward compatibility I allow transparent Read and Write to COM port > until a > special io control is received. > > The problem I am seeing today is more of a design concept problem. I don't > see a reason why a single application could make my driver not respond to > any > other application. This can be solved with some work but I would expect > KMDF > to provide some protection from such mistakes. Eventually there will be > some > programmer who will not consider this situation and release a driver that > can > be non responsive to all client applications because the lower level > driver > is blocking. > > Asaf 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). Regards, -- pa
From: Maxim S. Shatskih on 24 Aug 2010 15:41 > The problem I am seeing today is more of a design concept problem. I don't > see a reason why a single application could make my driver not respond to any > other application. So what? just kill the app and go on. OS-provided serial.sys has no such protection. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Asaf Shelly on 27 Aug 2010 01:14
Serial solved this by allow only one device access at a time, even though (if I remember correctly) it will allow a write operation while read is still blocking. Asaf "Maxim S. Shatskih" wrote: > > The problem I am seeing today is more of a design concept problem. I don't > > see a reason why a single application could make my driver not respond to any > > other application. > > So what? just kill the app and go on. > > OS-provided serial.sys has no such protection. > > -- > Maxim S. Shatskih > Windows DDK MVP > maxim(a)storagecraft.com > http://www.storagecraft.com > > . > |