One driver for different functions (interfaces)

[Marten_Lootsma]

Hi all,
This post is a continue from “Central driver with different interfaces”
what I post 4 January.

I get a lot of reactions and I thought it would be enough. But I can’t
find a good solution for our device.

We have a electronical measurement device on usb (with oscilosscope and
functiongenerator). Because we can’t support different interfaces in the
device it self we want to split the functionality in the driver. Just
create another interface with IoRegisterDeviceInterface is not enough.
We want to ‘see’ the driver in the Device Manager *in different
classes*. So the application can search for scope devices Or
functiongenarator devices.

I want to build one driver who talks with the measuerement device. And
create two interfaces, one for the Scope and one for a FunctionGenerator.
Who will be called when device is connected. On AddDevice I want to
create a main device object and the two different device objects who
representate the two functionalities of the device.

But strange enough IoRegisterDeviceInterface only accept the
PhysicalDeviceObject (as I understud). That’s why my first question is:
*Is it possible to create (and enable) an interface for own created
device objects?*

*Can I make one sys to handle all, fdo and the irp’s from the two
interfaces?*

If yes I want to setup a system like you can see in this picture.
http://www.mlcs.nl/driver.jpg

When a device is connected (AddDevice) I want to create also 3 threads.
Also one for the intrument and two for the interfaces. The comunicate
through Events. For example, the scope, the interface would contain the
settings for the next measurement for the scope. When the settings tell
that we need to measure, the central part will start a measure in the
device. When it’s ready the data will come into the interface and
availble for the applications.

Is that a good idea or is it totally wrong?

Thanks in advance
Marten Lootsma
(Student)

[Peter_Viscarola_OSR]

Marten Lootsma wrote:

I want to build one driver who talks with the measuerement device. And
create two interfaces, one for the Scope and one for a FunctionGenerator.
Who will be called when device is connected. On AddDevice I want to
create a main device object and the two different device objects who
representate the two functionalities of the device.

Is that a good idea or is it totally wrong?

Marten Lootsma
(Student)

Good thing you added the “student” tag

As I think a bunch of people explained to you last month, the best way
to do this is to create a simple bus driver. This would be
theInstrument driver in your picture.

Your instrument driver creates ONE device object and attaches that to
the underlying PDO.

Next, it creates one PDO for the SCOPE device and another PDO for the
FunctionGen device.

When you get your Query Device Relations for Bus Relations (often
referred to as “QDR”) you return the two PDOs you just created.

The PnP manager then queries you as to the hardware ID of these two
devices. You return some unique strings for each device found
(“MartenInstrument\Scope” and “MartenInstrument\FunctionGen” for example).

PnP Manager then looks for and loads the drivers for these two devices.

Bingo! You are DONE.

OK, so there’s a lot of hand-waving here, but it really does work just
like that. Yes, you’ll need to spend some time reading the docs and
looking at the (crufty) toaster bus sample driver.

Peter
OSR

[OSR_Community_User]

Can you explain in a little more detail why you feel it’s necessary to
have two separate devices rather than using multiple interfaces on a
single device.

Applications can (and should IMO) search for devices using device
interfaces rather than class interfaces. So your one device with two
different interfaces will still look like two separate things to your
applications.

Doing separate device objects requires you to build a bus driver. This
is orders of magnitude more difficult to get right than multiple device
interfaces. You can’t just register interfaces on any device object -
it has to be one that PNP recognizes as a PDO, and that requires that
you build a bus driver.

As for the threads - why do you need a dedicated thread for each
interface? How do these threads interact with the applciation threads
that send down requests?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Monday, January 24, 2005 8:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] One driver for different functions (interfaces)

Hi all,
This post is a continue from “Central driver with different
interfaces”
what I post 4 January.

I get a lot of reactions and I thought it would be enough.
But I can’t find a good solution for our device.

We have a electronical measurement device on usb (with
oscilosscope and functiongenerator). Because we can’t support
different interfaces in the device it self we want to split
the functionality in the driver. Just create another
interface with IoRegisterDeviceInterface is not enough.
We want to ‘see’ the driver in the Device Manager *in
different classes*. So the application can search for scope
devices Or functiongenarator devices.

I want to build one driver who talks with the measuerement
device. And create two interfaces, one for the Scope and one
for a FunctionGenerator.
Who will be called when device is connected. On AddDevice I
want to create a main device object and the two different
device objects who representate the two functionalities of the device.

But strange enough IoRegisterDeviceInterface only accept the
PhysicalDeviceObject (as I understud). That’s why my first
question is:
*Is it possible to create (and enable) an interface for own
created device objects?*

*Can I make one sys to handle all, fdo and the irp’s from the two
interfaces?*

If yes I want to setup a system like you can see in this picture.
http://www.mlcs.nl/driver.jpg

When a device is connected (AddDevice) I want to create also
3 threads.
Also one for the intrument and two for the interfaces. The
comunicate through Events. For example, the scope, the
interface would contain the settings for the next measurement
for the scope. When the settings tell that we need to
measure, the central part will start a measure in the device.
When it’s ready the data will come into the interface and
availble for the applications.

Is that a good idea or is it totally wrong?

Thanks in advance
Marten Lootsma
(Student)

---

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

[Marten_Lootsma]

Ok, lets say this is the way to go. How to communicate between the
‘interface driver’ and the ‘function driver’. Can I simply pass down the
IOCLs to the ‘function driver’ (there will be almost no function in the
interface driver). Or is it only possible to use interface get by
IRP_MN_QUERY_INTERFACE.

Marten

Peter Viscarola (OSR) wrote:

Marten Lootsma wrote:

>
> I want to build one driver who talks with the measuerement device. And
> create two interfaces, one for the Scope and one for a FunctionGenerator.
> Who will be called when device is connected. On AddDevice I want to
> create a main device object and the two different device objects who
> representate the two functionalities of the device.
>
>
> Is that a good idea or is it totally wrong?
>
> Marten Lootsma
> (Student)
>

Good thing you added the “student” tag

As I think a bunch of people explained to you last month, the best way
to do this is to create a simple bus driver. This would be
theInstrument driver in your picture.

Your instrument driver creates ONE device object and attaches that to
the underlying PDO.

Next, it creates one PDO for the SCOPE device and another PDO for the
FunctionGen device.

When you get your Query Device Relations for Bus Relations (often
referred to as “QDR”) you return the two PDOs you just created.

The PnP manager then queries you as to the hardware ID of these two
devices. You return some unique strings for each device found
(“MartenInstrument\Scope” and “MartenInstrument\FunctionGen” for example).

PnP Manager then looks for and loads the drivers for these two devices.

Bingo! You are DONE.

OK, so there’s a lot of hand-waving here, but it really does work just
like that. Yes, you’ll need to spend some time reading the docs and
looking at the (crufty) toaster bus sample driver.

Peter
OSR

[Marten_Lootsma]

Lets say we have a common application for different devices, one for
Fungens and one for Scopes. The application doesn’t know what devices
there can be, maybe there is a device more new then the application. But
when the have the same interface the application can open them.
The application is only interested in one of the device classes. So we
made different classes and search for their classguid.

Marten

Peter Wieland wrote:

Can you explain in a little more detail why you feel it’s necessary to
have two separate devices rather than using multiple interfaces on a
single device.
Applications can (and should IMO) search for devices using device
interfaces rather than class interfaces. So your one device with two
different interfaces will still look like two separate things to your
applications.

Doing separate device objects requires you to build a bus driver. This
is orders of magnitude more difficult to get right than multiple device
interfaces. You can’t just register interfaces on any device object -
it has to be one that PNP recognizes as a PDO, and that requires that
you build a bus driver.

As for the threads - why do you need a dedicated thread for each
interface? How do these threads interact with the applciation threads
that send down requests?

-p

>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
>Sent: Monday, January 24, 2005 8:12 AM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] One driver for different functions (interfaces)
>
>Hi all,
>This post is a continue from “Central driver with different
>interfaces”
>what I post 4 January.
>
>I get a lot of reactions and I thought it would be enough.
>But I can’t find a good solution for our device.
>
>We have a electronical measurement device on usb (with
>oscilosscope and functiongenerator). Because we can’t support
>different interfaces in the device it self we want to split
>the functionality in the driver. Just create another
>interface with IoRegisterDeviceInterface is not enough.
>We want to ‘see’ the driver in the Device Manager *in
>different classes*. So the application can search for scope
>devices Or functiongenarator devices.
>
>I want to build one driver who talks with the measuerement
>device. And create two interfaces, one for the Scope and one
>for a FunctionGenerator.
>Who will be called when device is connected. On AddDevice I
>want to create a main device object and the two different
>device objects who representate the two functionalities of the device.
>
>But strange enough IoRegisterDeviceInterface only accept the
>PhysicalDeviceObject (as I understud). That’s why my first
>question is:
>*Is it possible to create (and enable) an interface for own
>created device objects?*
>
>*Can I make one sys to handle all, fdo and the irp’s from the two
>interfaces?*
>
>If yes I want to setup a system like you can see in this picture.
>http://www.mlcs.nl/driver.jpg
>
>When a device is connected (AddDevice) I want to create also
>3 threads.
>Also one for the intrument and two for the interfaces. The
>comunicate through Events. For example, the scope, the
>interface would contain the settings for the next measurement
>for the scope. When the settings tell that we need to
>measure, the central part will start a measure in the device.
>When it’s ready the data will come into the interface and
>availble for the applications.
>
>Is that a good idea or is it totally wrong?
>
>Thanks in advance
>Marten Lootsma
>(Student)
>
>—
>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
>

[Marten_Lootsma]

What will happen if there are more of our devices connected? It will
open different ‘Intrument drivers’ and that will create the two others?

And who about the hardware ID, does it have to be unique on the system
or only for that device?

Peter Viscarola (OSR) wrote:

Marten Lootsma wrote:

>
> I want to build one driver who talks with the measuerement device. And
> create two interfaces, one for the Scope and one for a FunctionGenerator.
> Who will be called when device is connected. On AddDevice I want to
> create a main device object and the two different device objects who
> representate the two functionalities of the device.
>
>
> Is that a good idea or is it totally wrong?
>
> Marten Lootsma
> (Student)
>

Good thing you added the “student” tag

As I think a bunch of people explained to you last month, the best way
to do this is to create a simple bus driver. This would be
theInstrument driver in your picture.

Your instrument driver creates ONE device object and attaches that to
the underlying PDO.

Next, it creates one PDO for the SCOPE device and another PDO for the
FunctionGen device.

When you get your Query Device Relations for Bus Relations (often
referred to as “QDR”) you return the two PDOs you just created.

The PnP manager then queries you as to the hardware ID of these two
devices. You return some unique strings for each device found
(“MartenInstrument\Scope” and “MartenInstrument\FunctionGen” for example).

PnP Manager then looks for and loads the drivers for these two devices.

Bingo! You are DONE.

OK, so there’s a lot of hand-waving here, but it really does work just
like that. Yes, you’ll need to spend some time reading the docs and
looking at the (crufty) toaster bus sample driver.

Peter
OSR

[Maxim_S_Shatskih]

> create another interface with IoRegisterDeviceInterface is not enough.

We want to ‘see’ the driver in the Device Manager *in different
classes*.

Call IoRegisterDeviceInterface several times with different classes and
ReferenceStrings. This does the job.

Your CREATE path will see one of your ReferenceString as a file name, and can
decide what particular subdevice is being opened.

IIRC this is how sound devices work in Windows.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[Marten_Lootsma]

In the toaster example the are talk about WinXp/2000. Is it also
compatible with win98 and nt4?

Peter Viscarola (OSR) wrote:

Marten Lootsma wrote:

>
> I want to build one driver who talks with the measuerement device. And
> create two interfaces, one for the Scope and one for a FunctionGenerator.
> Who will be called when device is connected. On AddDevice I want to
> create a main device object and the two different device objects who
> representate the two functionalities of the device.
>
>
> Is that a good idea or is it totally wrong?
>
> Marten Lootsma
> (Student)
>

Good thing you added the “student” tag

As I think a bunch of people explained to you last month, the best way
to do this is to create a simple bus driver. This would be
theInstrument driver in your picture.

Your instrument driver creates ONE device object and attaches that to
the underlying PDO.

Next, it creates one PDO for the SCOPE device and another PDO for the
FunctionGen device.

When you get your Query Device Relations for Bus Relations (often
referred to as “QDR”) you return the two PDOs you just created.

The PnP manager then queries you as to the hardware ID of these two
devices. You return some unique strings for each device found
(“MartenInstrument\Scope” and “MartenInstrument\FunctionGen” for example).

PnP Manager then looks for and loads the drivers for these two devices.

Bingo! You are DONE.

OK, so there’s a lot of hand-waving here, but it really does work just
like that. Yes, you’ll need to spend some time reading the docs and
looking at the (crufty) toaster bus sample driver.

Peter
OSR

[OSR_Community_User]

Seems to me the best way to do things is to create a simple bus driver.

Take heart - it’s not that hard! I did one when I’d only been driver
programming a month or so ago. However, if you want to do this, then I
*strongly* suggest you get “Walter Oney 2nd ed.”, and start with the
example there. I had to make a few small changes to the PnP handling to
get it to work exactly the way I wanted, but it’s not rocket science…

MH.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: 24 January 2005 16:12
To: Windows System Software Devs Interest List
Subject: [ntdev] One driver for different functions (interfaces)

Hi all,
This post is a continue from “Central driver with different interfaces”
what I post 4 January.

This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.

[Maxim_S_Shatskih]

> What will happen if there are more of our devices connected? It will

open different ‘Intrument drivers’ and that will create the two others?

Your app must provide the UI to choose among the enumerated devices. Users love
to know with what piece of hardware they are working

And who about the hardware ID, does it have to be unique on the system

Hardware ID is vendor/model, must be unique for the devices on this kind.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

You are describing a bus driver. Your USB device function driver should
create PDO device objects and provide PnP query information about those PDOs
to the PnP manager. Each PDO will in turn have a function driver that
exposes a device interface.

See the toaster sample driver for some insight on how to code up a bus
driver.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Monday, January 24, 2005 11:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] One driver for different functions (interfaces)

Hi all,
This post is a continue from “Central driver with different interfaces”
what I post 4 January.

I get a lot of reactions and I thought it would be enough. But I can’t find
a good solution for our device.

We have a electronical measurement device on usb (with oscilosscope and
functiongenerator). Because we can’t support different interfaces in the
device it self we want to split the functionality in the driver. Just create
another interface with IoRegisterDeviceInterface is not enough.
We want to ‘see’ the driver in the Device Manager *in different classes*. So
the application can search for scope devices Or functiongenarator devices.

I want to build one driver who talks with the measuerement device. And
create two interfaces, one for the Scope and one for a FunctionGenerator.
Who will be called when device is connected. On AddDevice I want to create a
main device object and the two different device objects who representate the
two functionalities of the device.

But strange enough IoRegisterDeviceInterface only accept the
PhysicalDeviceObject (as I understud). That’s why my first question is:
*Is it possible to create (and enable) an interface for own created device
objects?*

*Can I make one sys to handle all, fdo and the irp’s from the two
interfaces?*

If yes I want to setup a system like you can see in this picture.
http://www.mlcs.nl/driver.jpg

When a device is connected (AddDevice) I want to create also 3 threads.
Also one for the intrument and two for the interfaces. The comunicate
through Events. For example, the scope, the interface would contain the
settings for the next measurement for the scope. When the settings tell that
we need to measure, the central part will start a measure in the device.
When it’s ready the data will come into the interface and availble for the
applications.

Is that a good idea or is it totally wrong?

Thanks in advance
Marten Lootsma
(Student)

---

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

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

[Peter_Viscarola_OSR]

Marten Lootsma wrote:

Ok, lets say this is the way to go. How to communicate between the
‘interface driver’ and the ‘function driver’. Can I simply pass down the
IOCLs to the ‘function driver’ (there will be almost no function in the
interface driver).

Yes. You just IoCallDriver the IRPs from the Function and Scope drivers
to the underlying bus driver.

One small correction though: You’d be passing the IRPs from the FUNCTION
drivers (function and scope) to the immediately underlying PDO created
by the BUS driver. You get this PDO in response to the FUNCTION drivers
calling IoAttachDeviceToDeviceStack in their AddDevice entry point.

In the FunctionGen and Scope driver’s AddDevice:

DeviceToSendIrpsTo = IoAttachDeviceToDeviceStack(…);

In the FunctionGen and Scope driver’s dispatch routines:

IoCopyCurrentIrpStackLocationToNext(…);
status = IoCallDriver(Irp, DeviceToSendIrpsTo);
return(status);

Assuming you don’t put a completion routine in the IRPs, that really is
all there is to it.

Oh yeah… That and power management…

Peter
OSR

Or is it only possible to use interface get by
IRP_MN_QUERY_INTERFACE.

[Peter_Viscarola_OSR]

Marten Lootsma wrote:

In the toaster example the are talk about WinXp/2000. Is it also
compatible with win98 and nt4?

NO. Windows NT V4 does not share a common interface with Win98.

If written carefully, a Windows 2000/XP compatible driver MIGHT work on
Win98.

Your mileage may vary,

Peter
OSR

[Peter_Viscarola_OSR]

Marten Lootsma wrote:

What will happen if there are more of our devices connected? It will
open different ‘Intrument drivers’ and that will create the two others?

Yes.

And who about the hardware ID, does it have to be unique on the system
or only for that device?

(it might be better to put all these questions in a single email

Only for that device.

Peter
OSR

[OSR_Community_User]

Searching for the class guid is essentially the same as iterating over a
device interface. If you take the approach of registering 2 device
interfaces w/diff reference strings on the same device (ie not a bus
driver) and there are 2 instances of your device, when you iterate over
the device interface instances, you will see 2 (just like you would see
2 instances of the class guid). Now, you are making an assumption that
the class guid == device interface in terms of supported functionality.
Not always true.

As a good example, take the usb device class. Under it, there are USB
controllers, USB hubs, and random USB devices who didn’t pick their own
device class. There is a distinct device interface for each one and
none share the same interface.

In the end, even if you have device class guid enumeration, you still
need to open the instance of the class guid. The class guid itself is
of no use. Again, device interfaces give you the name to open.

I strongly encourage you to use 2 device interfaces w/reference strings
vs creating a bus driver. Creating a bus driver is simple on the
outset, but there are many many many details to get right and lots of
them don’t show up until much later in the development process. By
keeping it simpler (no bus driver), you are creating a more maintainable
driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Tuesday, January 25, 2005 12:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] One driver for different functions (interfaces)

Lets say we have a common application for different devices, one for
Fungens and one for Scopes. The application doesn’t know what devices
there can be, maybe there is a device more new then the application. But

when the have the same interface the application can open them.
The application is only interested in one of the device classes. So we
made different classes and search for their classguid.

Marten

Peter Wieland wrote:

Can you explain in a little more detail why you feel it’s necessary to
have two separate devices rather than using multiple interfaces on a
single device.
Applications can (and should IMO) search for devices using
device
interfaces rather than class interfaces. So your one device with two
different interfaces will still look like two separate things to your
applications.

Doing separate device objects requires you to build a bus driver.
This
is orders of magnitude more difficult to get right than multiple
device
interfaces. You can’t just register interfaces on any device object -
it has to be one that PNP recognizes as a PDO, and that requires that
you build a bus driver.

As for the threads - why do you need a dedicated thread for each
interface? How do these threads interact with the applciation threads
that send down requests?

-p

>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
>Sent: Monday, January 24, 2005 8:12 AM
>To: Windows System Software Devs Interest List
>Subject: [ntdev] One driver for different functions (interfaces)
>
>Hi all,
>This post is a continue from “Central driver with different
>interfaces”
>what I post 4 January.
>
>I get a lot of reactions and I thought it would be enough.
>But I can’t find a good solution for our device.
>
>We have a electronical measurement device on usb (with
>oscilosscope and functiongenerator). Because we can’t support
>different interfaces in the device it self we want to split
>the functionality in the driver. Just create another
>interface with IoRegisterDeviceInterface is not enough.
>We want to ‘see’ the driver in the Device Manager *in
>different classes*. So the application can search for scope
>devices Or functiongenarator devices.
>
>I want to build one driver who talks with the measuerement
>device. And create two interfaces, one for the Scope and one
>for a FunctionGenerator.
>Who will be called when device is connected. On AddDevice I
>want to create a main device object and the two different
>device objects who representate the two functionalities of the device.
>
>But strange enough IoRegisterDeviceInterface only accept the
>PhysicalDeviceObject (as I understud). That’s why my first
>question is:
>*Is it possible to create (and enable) an interface for own
>created device objects?*
>
>*Can I make one sys to handle all, fdo and the irp’s from the two
>interfaces?*
>
>If yes I want to setup a system like you can see in this picture.
>http://www.mlcs.nl/driver.jpg
>
>When a device is connected (AddDevice) I want to create also
>3 threads.
>Also one for the intrument and two for the interfaces. The
>comunicate through Events. For example, the scope, the
>interface would contain the settings for the next measurement
>for the scope. When the settings tell that we need to
>measure, the central part will start a measure in the device.
>When it’s ready the data will come into the interface and
>availble for the applications.
>
>Is that a good idea or is it totally wrong?
>
>Thanks in advance
>Marten Lootsma
>(Student)
>
>—
>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
>

---

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

[OSR_Community_User]

If you are a bus driver, the PDO (child) can fwd the IRP to the FDO
(parent). If both the PDO and FDO use a stack location (vs the FDO
sharing the same stack location that the PDO uses), you need to make
sure that the PDO->StackSize = Fdo->StackSize +1. If they share,
Pdo->StackSize = 1.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Tuesday, January 25, 2005 12:00 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] One driver for different functions (interfaces)

Ok, lets say this is the way to go. How to communicate between the
‘interface driver’ and the ‘function driver’. Can I simply pass down the

IOCLs to the ‘function driver’ (there will be almost no function in the
interface driver). Or is it only possible to use interface get by
IRP_MN_QUERY_INTERFACE.

Marten

Peter Viscarola (OSR) wrote:

Marten Lootsma wrote:

>
> I want to build one driver who talks with the measuerement device.
And
> create two interfaces, one for the Scope and one for a
FunctionGenerator.
> Who will be called when device is connected. On AddDevice I want to
> create a main device object and the two different device objects who
> representate the two functionalities of the device.
>
>
> Is that a good idea or is it totally wrong?
>
> Marten Lootsma
> (Student)
>

Good thing you added the “student” tag

As I think a bunch of people explained to you last month, the best way

to do this is to create a simple bus driver. This would be
theInstrument driver in your picture.

Your instrument driver creates ONE device object and attaches that to
the underlying PDO.

Next, it creates one PDO for the SCOPE device and another PDO for the
FunctionGen device.

When you get your Query Device Relations for Bus Relations (often
referred to as “QDR”) you return the two PDOs you just created.

The PnP manager then queries you as to the hardware ID of these two
devices. You return some unique strings for each device found
(“MartenInstrument\Scope” and “MartenInstrument\FunctionGen” for
example).

PnP Manager then looks for and loads the drivers for these two
devices.

Bingo! You are DONE.

OK, so there’s a lot of hand-waving here, but it really does work just

like that. Yes, you’ll need to spend some time reading the docs and
looking at the (crufty) toaster bus sample driver.

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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

You want to create a bus driver. Each of the children will be your
distinct function. This way you see both functions as separate entities
in device manager.

As for the threads, that seems heavy handed to me and doesn’t scale well
when you have multiple instances of your device. Usually you can do the
synchronizawtion with some circular ring buffers and w/out waiting by
doing processing in a DPC routine with some simple state machine logic.
But, I don’t have to maintain the code, you do :)…so you should do
what you think is the easiest to maintain and debug over time.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Monday, January 24, 2005 8:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] One driver for different functions (interfaces)

Hi all,
This post is a continue from “Central driver with different interfaces”
what I post 4 January.

I get a lot of reactions and I thought it would be enough. But I can’t
find a good solution for our device.

We have a electronical measurement device on usb (with oscilosscope and
functiongenerator). Because we can’t support different interfaces in the

device it self we want to split the functionality in the driver. Just
create another interface with IoRegisterDeviceInterface is not enough.
We want to ‘see’ the driver in the Device Manager *in different
classes*. So the application can search for scope devices Or
functiongenarator devices.

I want to build one driver who talks with the measuerement device. And
create two interfaces, one for the Scope and one for a
FunctionGenerator.
Who will be called when device is connected. On AddDevice I want to
create a main device object and the two different device objects who
representate the two functionalities of the device.

But strange enough IoRegisterDeviceInterface only accept the
PhysicalDeviceObject (as I understud). That’s why my first question is:
*Is it possible to create (and enable) an interface for own created
device objects?*

*Can I make one sys to handle all, fdo and the irp’s from the two
interfaces?*

If yes I want to setup a system like you can see in this picture.
http://www.mlcs.nl/driver.jpg

When a device is connected (AddDevice) I want to create also 3 threads.
Also one for the intrument and two for the interfaces. The comunicate
through Events. For example, the scope, the interface would contain the
settings for the next measurement for the scope. When the settings tell
that we need to measure, the central part will start a measure in the
device. When it’s ready the data will come into the interface and
availble for the applications.

Is that a good idea or is it totally wrong?

Thanks in advance
Marten Lootsma
(Student)

---

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

[OSR_Community_User]

2 ways:

1. Pass the IoCtls and other requests down to the main FDO (if you’ve
   implemented your bus driver right, this will be more or less default
   behaviour for many IRP’s).

2. Do absolutely anything you want that’s private to your driver… Eg,
   look up PDO and parent FDO in a local table, obtain a set of function
   pointers for services supported by that PDO, and then call a bunch of
   functions which involve one or both of PDO and FDO. Anything goes
   provided it’s not stupid (1).

MH.

(1) That could be said for most driver programming: anything goes,
except the 8 million things you shouldn’t do.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: 25 January 2005 08:00
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] One driver for different functions (interfaces)

Ok, lets say this is the way to go. How to communicate between the
‘interface driver’ and the ‘function driver’. Can I simply pass down the
IOCLs to the ‘function driver’ (there will be almost no function in the
interface driver). Or is it only possible to use interface get by
IRP_MN_QUERY_INTERFACE.

Marten

Peter Viscarola (OSR) wrote:

Marten Lootsma wrote:

>
> I want to build one driver who talks with the measuerement device.
> And create two interfaces, one for the Scope and one for a
FunctionGenerator.
> Who will be called when device is connected. On AddDevice I want to
> create a main device object and the two different device objects who
> representate the two functionalities of the device.
>
>
> Is that a good idea or is it totally wrong?
>
> Marten Lootsma
> (Student)
>

Good thing you added the “student” tag

As I think a bunch of people explained to you last month, the best way

to do this is to create a simple bus driver. This would be
theInstrument driver in your picture.

Your instrument driver creates ONE device object and attaches that to
the underlying PDO.

Next, it creates one PDO for the SCOPE device and another PDO for the
FunctionGen device.

When you get your Query Device Relations for Bus Relations (often
referred to as “QDR”) you return the two PDOs you just created.

The PnP manager then queries you as to the hardware ID of these two
devices. You return some unique strings for each device found
(“MartenInstrument\Scope” and “MartenInstrument\FunctionGen” for
example).

PnP Manager then looks for and loads the drivers for these two
devices.

Bingo! You are DONE.

OK, so there’s a lot of hand-waving here, but it really does work just

like that. Yes, you’ll need to spend some time reading the docs and
looking at the (crufty) toaster bus sample driver.

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@snellwilcox.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.

[OSR_Community_User]

Just so that I can be on all sides of this issue, he can also implement the
other suggestion: multiple interfaces for a single functional device object.
I thought from his post that there was some technical obstacle that
prevented him from implementing two logical NT device interfaces (not to be
confused with USB interfaces) for his single USB device. On re-reading it, I
don’t see what the obstacle is and think that perhaps the easiest approach
is to use the multiple interface single device approach. Heck, he doesn’t
actually even have to have two distinct interfaces, he could use one
interface and then open it with a path name that identifies which logical
function he wants to communicate with. All of which is perhaps simpler than
implementing a bus driver and multiple function drivers.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 24, 2005 12:19 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] One driver for different functions (interfaces)

You want to create a bus driver. Each of the children will be your distinct
function. This way you see both functions as separate entities in device
manager.

As for the threads, that seems heavy handed to me and doesn’t scale well
when you have multiple instances of your device. Usually you can do the
synchronizawtion with some circular ring buffers and w/out waiting by doing
processing in a DPC routine with some simple state machine logic.
But, I don’t have to maintain the code, you do :)…so you should do what
you think is the easiest to maintain and debug over time.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Monday, January 24, 2005 8:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] One driver for different functions (interfaces)

Hi all,
This post is a continue from “Central driver with different interfaces”
what I post 4 January.

I get a lot of reactions and I thought it would be enough. But I can’t find
a good solution for our device.

We have a electronical measurement device on usb (with oscilosscope and
functiongenerator). Because we can’t support different interfaces in the

device it self we want to split the functionality in the driver. Just create
another interface with IoRegisterDeviceInterface is not enough.
We want to ‘see’ the driver in the Device Manager *in different classes*. So
the application can search for scope devices Or functiongenarator devices.

I want to build one driver who talks with the measuerement device. And
create two interfaces, one for the Scope and one for a FunctionGenerator.
Who will be called when device is connected. On AddDevice I want to create a
main device object and the two different device objects who representate the
two functionalities of the device.

But strange enough IoRegisterDeviceInterface only accept the
PhysicalDeviceObject (as I understud). That’s why my first question is:
*Is it possible to create (and enable) an interface for own created device
objects?*

*Can I make one sys to handle all, fdo and the irp’s from the two
interfaces?*

If yes I want to setup a system like you can see in this picture.
http://www.mlcs.nl/driver.jpg

When a device is connected (AddDevice) I want to create also 3 threads.
Also one for the intrument and two for the interfaces. The comunicate
through Events. For example, the scope, the interface would contain the
settings for the next measurement for the scope. When the settings tell that
we need to measure, the central part will start a measure in the device.
When it’s ready the data will come into the interface and availble for the
applications.

Is that a good idea or is it totally wrong?

Thanks in advance
Marten Lootsma
(Student)

---

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

---

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

[OSR_Community_User]

NT4: definitely not. There is no PNP there.
Win9x: probably not, I am pretty sure it was not tested on that OS.

If you want win9x support, definitely get walter oney’s book and read up
on the win9x compat section.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marten Lootsma
Sent: Tuesday, January 25, 2005 12:30 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] One driver for different functions (interfaces)

In the toaster example the are talk about WinXp/2000. Is it also
compatible with win98 and nt4?

Peter Viscarola (OSR) wrote:

Marten Lootsma wrote:

>
> I want to build one driver who talks with the measuerement device.
And
> create two interfaces, one for the Scope and one for a
FunctionGenerator.
> Who will be called when device is connected. On AddDevice I want to
> create a main device object and the two different device objects who
> representate the two functionalities of the device.
>
>
> Is that a good idea or is it totally wrong?
>
> Marten Lootsma
> (Student)
>

Good thing you added the “student” tag

As I think a bunch of people explained to you last month, the best way

to do this is to create a simple bus driver. This would be
theInstrument driver in your picture.

Your instrument driver creates ONE device object and attaches that to
the underlying PDO.

Next, it creates one PDO for the SCOPE device and another PDO for the
FunctionGen device.

When you get your Query Device Relations for Bus Relations (often
referred to as “QDR”) you return the two PDOs you just created.

The PnP manager then queries you as to the hardware ID of these two
devices. You return some unique strings for each device found
(“MartenInstrument\Scope” and “MartenInstrument\FunctionGen” for
example).

PnP Manager then looks for and loads the drivers for these two
devices.

Bingo! You are DONE.

OK, so there’s a lot of hand-waving here, but it really does work just

like that. Yes, you’ll need to spend some time reading the docs and
looking at the (crufty) toaster bus sample driver.

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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com