Central driver with different interfaces

NTDEV
1

Hi
We are working an a driver for USB device with multi (non-standard)
functions.
Now we have a good working central driver who can handle all the
functions. But we want to show the driver separated, so a application
can open sub device ‘X’ or sub device ‘Y’. Both routed through our
current driver.

So we was thinking about two parallel filterdrivers (if this is
possible) who are just passing through userapp IRPs filtered on function.

Is this a good way of thinking?

NOTE: We want to keep a central driver because some settings in sub
device ‘X’ might effect the other sub device ‘Y’.

Tnx
Marten Lootsma

2

Why not simply create two devices by your driver? they will be managed
through the same driver…
Anyway, it is not possible to write two parallel filter drivers, because
drivers are stacked on one another.

“Marten Lootsma” wrote in message news:xxxxx@ntdev…
> Hi
> We are working an a driver for USB device with multi (non-standard)
> functions.
> Now we have a good working central driver who can handle all the
> functions. But we want to show the driver separated, so a application can
> open sub device ‘X’ or sub device ‘Y’. Both routed through our current
> driver.
>
> So we was thinking about two parallel filterdrivers (if this is possible)
> who are just passing through userapp IRPs filtered on function.
>
> Is this a good way of thinking?
>
> NOTE: We want to keep a central driver because some settings in sub device
> ‘X’ might effect the other sub device ‘Y’.
>
> Tnx
> Marten Lootsma
>

3

Thanks for fast response.

I think we can use it. But when I imagine to open two device object I
think it’s not possible to share their DEVICE_EXTENSION. And we want
that one part ‘have contact’ with the device through USB.

Is that possible in this situation?

Here you can find a sketch of how I think it should be.
http://www.mlcs.nl/driver_layout.gif

Ori Hanegby wrote:

Why not simply create two devices by your driver? they will be managed
through the same driver…
Anyway, it is not possible to write two parallel filter drivers, because
drivers are stacked on one another.

“Marten Lootsma” wrote in message news:xxxxx@ntdev…
>
>>Hi
>>We are working an a driver for USB device with multi (non-standard)
>>functions.
>>Now we have a good working central driver who can handle all the
>>functions. But we want to show the driver separated, so a application can
>>open sub device ‘X’ or sub device ‘Y’. Both routed through our current
>>driver.
>>
>>So we was thinking about two parallel filterdrivers (if this is possible)
>>who are just passing through userapp IRPs filtered on function.
>>
>>Is this a good way of thinking?
>>
>>NOTE: We want to keep a central driver because some settings in sub device
>>‘X’ might effect the other sub device ‘Y’.
>>
>>Tnx
>>Marten Lootsma
>>
>
>
>
>

4

> I think we can use it. But when I imagine to open

two device object I
think it’s not possible to share their
DEVICE_EXTENSION. And we want
that one part ‘have contact’ with the device through
USB.

Is that possible in this situation?

What do you mean by “share their DEVICE_EXTENSION”?
What are trying to achieve? Try providing more
details.

Best regards,
Razvan

Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
http://celebrity.mail.yahoo.com

5

Here you can find a sketch of how I think it should be.
http://www.mlcs.nl/driver_layout.gif

Now (in the current driver) we stored information, like settings of the
hardware, in DEVICE_EXTENSION. The hardware settings are depending on
both functionalities from the device. So even when we have two different
DEVICE_OBJECT we would like to have the hardware settings central, se we
can send this information from one place to the device.

Razvan Hobeanu wrote:

>I think we can use it. But when I imagine to open
>two device object I
>think it’s not possible to share their
>DEVICE_EXTENSION. And we want
>that one part ‘have contact’ with the device through
>USB.
>
>Is that possible in this situation?

What do you mean by “share their DEVICE_EXTENSION”?
What are trying to achieve? Try providing more
details.

Best regards,
Razvan

Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
http://celebrity.mail.yahoo.com

6

The “device extension” is resident ( non-paged ) as long as the device object exists. So it is
possible to access it from another device object , but NOT RECOMMENDED at all !
But why don’t you grab some memory ( non-page or paged-if-allowed ) and store a pointer
to it globally in the data segment of the driver ? Then you can access this “common” data from
anywhere in your driver. Just take care about synchronization when writing to this common
memory.

Christiaan

----- Original Message -----
From: “Marten Lootsma”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, December 30, 2004 3:01 PM
Subject: Re:[ntdev] Central driver with different interfaces

>
> Here you can find a sketch of how I think it should be.
> http://www.mlcs.nl/driver_layout.gif
>
> Now (in the current driver) we stored information, like settings of the
> hardware, in DEVICE_EXTENSION. The hardware settings are depending on
> both functionalities from the device. So even when we have two different
> DEVICE_OBJECT we would like to have the hardware settings central, se we
> can send this information from one place to the device.
>
> Razvan Hobeanu wrote:
> >>I think we can use it. But when I imagine to open
> >>two device object I
> >>think it’s not possible to share their
> >>DEVICE_EXTENSION. And we want
> >>that one part ‘have contact’ with the device through
> >>USB.
> >>
> >>Is that possible in this situation?
> >
> >
> > What do you mean by “share their DEVICE_EXTENSION”?
> > What are trying to achieve? Try providing more
> > details.
> >
> > Best regards,
> > Razvan
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Send a seasonal email greeting and help others. Do good.
> > http://celebrity.mail.yahoo.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

7

>

Now (in the current driver) we stored information, like settings of the
hardware, in DEVICE_EXTENSION. The hardware settings are depending on
both functionalities from the device. So even when we have two different
DEVICE_OBJECT we would like to have the hardware settings central, se we
can send this information from one place to the device.

So, this is now a programming question and not a design issue, is that
right?

Personally, what I’d suggest is that you create 3 device objects: One
that desscribes the overall state of your hardware, and the other two
that represent functions X and Y on your device.

This keeps the hardware state and user interface state where it should be.

Speaking of which, what you SHOULD have are two separate USB INTERFACES,
right? This would allow TWO separate drivers to load, and you wouldn’t
have this problem. Why not change the device’s USB descriptor and fix
this the right way?

Peter
OSR

8

> Hi

We are working an a driver for USB device with multi (non-standard)
functions.
Now we have a good working central driver who can handle all the
functions. But we want to show the driver separated, so a application
can open sub device ‘X’ or sub device ‘Y’. Both routed through our
current driver.

This seems, on the surface, like a case that could be handled by
simply registering multiple interfaces for the device. This is,
however, something that I have never done. If multiple
interfaces are registered is there any way to find out which interface
instance is being opened inside the dispatch routing for IRP_MJ_CREATE?

Robert Newton

9

For any dispatch routine the specific device object being referenced is
passed as a parameter.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Robert Newton” wrote in message
news:xxxxx@ntdev…
> > Hi
> > We are working an a driver for USB device with multi (non-standard)
> > functions.
> > Now we have a good working central driver who can handle all the
> > functions. But we want to show the driver separated, so a application
> > can open sub device ‘X’ or sub device ‘Y’. Both routed through our
> > current driver.
> >
>
> This seems, on the surface, like a case that could be handled by
> simply registering multiple interfaces for the device. This is,
> however, something that I have never done. If multiple
> interfaces are registered is there any way to find out which interface
> instance is being opened inside the dispatch routing for IRP_MJ_CREATE?
>
>
> Robert Newton
>
>
>

10

It’s good to hear your suggestion about 3 device object. It seems a good
solution to us.

But how it’s going on a remove from the device? Who will get the message
first? When we share data, where is it safe to free that memory. Maybe a
own made refcount and on zero the memory can be free’d, or are there
better (offical) ways?

Why we don’t use the standard solution? De device we have connected is
very pasive. The resources on the device is separated between the two
sub functionalities. When one is taking more, the other has less. This
we need to organize central. But in de device there is not enough power
to do that.

And the driver works already fine. But we want let it look like
separated devices. In the driver it’s already well separated. There is a
settings array written by userside and the hardwareside reads it and put
it to the hardware. So I think that array is a the part the device
obecjets will share.

About the definision of my question: We are orientating what how we can
change our driver to what we want. I think it’s a design issue, but we
need to know also of we can realize it with programming…

Tnx
Marten Lootsma

Peter Viscarola (OSR) wrote:

>
> Now (in the current driver) we stored information, like settings of
> the hardware, in DEVICE_EXTENSION. The hardware settings are depending
> on both functionalities from the device. So even when we have two
> different DEVICE_OBJECT we would like to have the hardware settings
> central, se we can send this information from one place to the device.
>

So, this is now a programming question and not a design issue, is that
right?

Personally, what I’d suggest is that you create 3 device objects: One
that desscribes the overall state of your hardware, and the other two
that represent functions X and Y on your device.

This keeps the hardware state and user interface state where it should be.

Speaking of which, what you SHOULD have are two separate USB INTERFACES,
right? This would allow TWO separate drivers to load, and you wouldn’t
have this problem. Why not change the device’s USB descriptor and fix
this the right way?

Peter
OSR

11

Most of your concerns are addressed in the pnp bus driver design paradigm.
If you enumerate your functions as child devices of a ‘parent’ usb function
driver, then removal in all of its flavors will work correctly. By the way,
it isn’t just remove that can be an issue here, it is power management and
resource rebalancing (start/stop) as well that have issues that are at least
addressed if not entirely resolved by the bus driver design.

You might want to investigate the existing multifunction bus driver, mf.sys,
as it provides a standard implementation that can work for many ‘resource
sharing’ ‘non-standard’ multifunction devices. The documentation is a bit
lacking, but we have discussed most of the issues here on this list (I
think) so searching may produce some clues.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Thursday, December 30, 2004 2:27 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Central driver with different interfaces

It’s good to hear your suggestion about 3 device object. It
seems a good solution to us.

But how it’s going on a remove from the device? Who will get
the message first? When we share data, where is it safe to
free that memory. Maybe a own made refcount and on zero the
memory can be free’d, or are there better (offical) ways?

Why we don’t use the standard solution? De device we have
connected is very pasive. The resources on the device is
separated between the two sub functionalities. When one is
taking more, the other has less. This we need to organize
central. But in de device there is not enough power to do that.

And the driver works already fine. But we want let it look
like separated devices. In the driver it’s already well
separated. There is a settings array written by userside and
the hardwareside reads it and put it to the hardware. So I
think that array is a the part the device obecjets will share.

About the definision of my question: We are orientating what
how we can change our driver to what we want. I think it’s a
design issue, but we need to know also of we can realize it
with programming…

Tnx
Marten Lootsma

Peter Viscarola (OSR) wrote:
>>
>> Now (in the current driver) we stored information, like
settings of
>> the hardware, in DEVICE_EXTENSION. The hardware settings are
>> depending on both functionalities from the device. So even when we
>> have two different DEVICE_OBJECT we would like to have the
hardware
>> settings central, se we can send this information from one
place to the device.
>>
>
> So, this is now a programming question and not a design
issue, is that
> right?
>
> Personally, what I’d suggest is that you create 3 device
objects: One
> that desscribes the overall state of your hardware, and the
other two
> that represent functions X and Y on your device.
>
> This keeps the hardware state and user interface state
where it should be.
>
> Speaking of which, what you SHOULD have are two separate USB
> INTERFACES, right? This would allow TWO separate drivers
to load, and
> you wouldn’t have this problem. Why not change the device’s USB
> descriptor and fix this the right way?
>
> Peter
> OSR
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

12

When you create an interface, I believe you can add an “alias” to the
interface - some unique bit of fluff that gets put into the name the
symobolic link uses. You can check the file object name on a create to
see if it matches that bit of fluff in order to distinguish between
opens of the various interfaces.

One device object, multiple interfaces.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert Newton
Sent: Thursday, December 30, 2004 10:40 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Central driver with different interfaces

Hi
We are working an a driver for USB device with multi (non-standard)
functions.
Now we have a good working central driver who can handle all the
functions. But we want to show the driver separated, so a application
can open sub device ‘X’ or sub device ‘Y’. Both routed through our
current driver.

This seems, on the surface, like a case that could be handled by simply
registering multiple interfaces for the device. This is, however,
something that I have never done. If multiple interfaces are registered
is there any way to find out which interface instance is being opened
inside the dispatch routing for IRP_MJ_CREATE?

Robert Newton

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com