A Design Decision.

NTDEV
1

Hi All,
First of all some back ground.

  1. We have a WDM driver for a video decoder hardware. This WDM driver support only one application decode at a time.

  2. We have a DIL (Driver Interface Library, a dll) which abstracts all the driver IOCTLS. All applications talk to DIL which in turn talks to driver.

  3. We are trying to add multiple application support to the solution.

My team has been thinking about this for quite some time now and we understand that the correct solution will be to redesign/modify the driver to let it handle the multiple applications. There is another suggestion that we can modify the DIL and enable it to acquire a shared lock (and talk to different instances through IPC) when a particular application is doing some processing. This way we can keep the driver same and with some changes in DIL we will be able to achieve a solution which may not be optimal but might work. This saves development time.

Really speaking I hate this solution because I know this is not the way to do this.
Can someone there give me opinions about the correct approach and reasons why one is better than other.

It will be a great help.
Thanks in Advance.
– Aj.

2

I would prefer a solution where DIL handles all synchronization issues. It should be easiest design. Otherwise you need to do this in the driver which may be more difficult compare to the first solution.
The bottom line is you should move as much stuff as possible from kernel to application level. Of course if this move would not decrease performance. But to give to you the best advise we need to look your current design and intended modification more deeply.

Igor Sharovar

3

By putting the logic in the dil, you are to go down a very complicated path
1 since you are going to use some ipc, you now need a protocol to find all other instances if the dll
2 you now need some kind of locking and that will allow one app to block another now
3 if an app dies while the lock is held, you need to be able to recover
4 if the driver is exclusive open, you still have to modify the driver to allow concurrent handles

Imho, fixing the driver will lead to a cleaner solution in the long run

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Ajitabh Saxena
Sent: Thursday, February 18, 2010 2:49 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] A Design Decision.

Hi All,
First of all some back ground.

1. We have a WDM driver for a video decoder hardware. This WDM driver support only one application decode at a time.

2. We have a DIL (Driver Interface Library, a dll) which abstracts all the driver IOCTLS. All applications talk to DIL which in turn talks to driver.

3. We are trying to add multiple application support to the solution.

My team has been thinking about this for quite some time now and we understand that the correct solution will be to redesign/modify the driver to let it handle the multiple applications. There is another suggestion that we can modify the DIL and enable it to acquire a shared lock (and talk to different instances through IPC) when a particular application is doing some processing. This way we can keep the driver same and with some changes in DIL we will be able to achieve a solution which may not be optimal but might work. This saves development time.

Really speaking I hate this solution because I know this is not the way to do this.
Can someone there give me opinions about the correct approach and reasons why one is better than other.

It will be a great help.
Thanks in Advance.
– Aj.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Fix the driver.

The whole point of having the interface DLL is most typically to hide the details of DeviceIoControl from user-mode programmers. You want them to call “StartTheEngine” instead of coding up an IOCTL with IOCTL_ENGINE_START function code. In this role, you ideally want the interface DLL to be a thin, stateless, SIMPLE layer. This simplifies debugging (for you the driver dev and the application writer), and even simplifies your maintenance.

There’s a natural tendency to want to keep “value adding” the interface library, but this can get ugly quickly if you’re not careful.

If fixing the driver is REALLY that onerous (I have no idea what you might need to do)… you could consider implementing a centralized service component: The user apps talk to the interface DLL as they do now, using the same calls if you like, but that interface DLL sends requests to a user interface service. That service is then responsible for sending requests (all appropriately serialized or whatever) to your driver. In this scheme – which is a ton of work – you at least have a clear mechanism for dealing with unexpected failure of an individual application.

But, again… unless you REALLY want to keep your hands off the driver, this would be gross overkill.

The point is that drivers are all set up with mechanisms to deal with multiple open instances (file objects and their handles) and storing context based on each instance.

Seriously… Fix the driver.

Peter
OSR

5

I cannot agree more…I will have to try to convience my team more.
– Ajitabh.

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com [xxxxx@osr.com]
Sent: Thursday, February 18, 2010 3:50 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] A Design Decision.

Fix the driver.

The whole point of having the interface DLL is most typically to hide the details of DeviceIoControl from user-mode programmers. You want them to call “StartTheEngine” instead of coding up an IOCTL with IOCTL_ENGINE_START function code. In this role, you ideally want the interface DLL to be a thin, stateless, SIMPLE layer. This simplifies debugging (for you the driver dev and the application writer), and even simplifies your maintenance.

There’s a natural tendency to want to keep “value adding” the interface library, but this can get ugly quickly if you’re not careful.

If fixing the driver is REALLY that onerous (I have no idea what you might need to do)… you could consider implementing a centralized service component: The user apps talk to the interface DLL as they do now, using the same calls if you like, but that interface DLL sends requests to a user interface service. That service is then responsible for sending requests (all appropriately serialized or whatever) to your driver. In this scheme – which is a ton of work – you at least have a clear mechanism for dealing with unexpected failure of an individual application.

But, again… unless you REALLY want to keep your hands off the driver, this would be gross overkill.

The point is that drivers are all set up with mechanisms to deal with multiple open instances (file objects and their handles) and storing context based on each instance.

Seriously… Fix the driver.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

>suggestion that we can modify the DIL

Throw away the DIL and remake the driver to be AVStream one.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com