Question on right way to proceed

NTDEV
1

A company I’m associated with has a device that interfaces to the scsi bus
and calls itself a processor class device. In the past, the application
program that uses this has enumerated the scsi busses by successively
opening \scsi0 to scsiN and doing a bus scan for the device. On finding
it, the application uses scsi passthru to send and receive raw scsi packets.

With modern USB adapters this is failing because the adapters don’t name
themselves scsnN devices any more. Attempts by another programmer at using
the SetupDI interfaced to enumerate the scsi busses were unsuccessful. I
don’t kow of this was failure of imagination or something else going wrong;
I’ll be experimenting with that today.

But it seems the right way to go is to install a real driver for this
device. The driver would really do nothing more than identify itself
correctly, have a resolvable name (for the application program) and just
pass the scsi passthru packets through.

Where should I start to make such a driver? Should I expect any problems in
particular to be aware of?

Loren

2

You could scan the hardware tree through the PNP API for devices with
the right HWID.

If you’re going to write such a driver suggest you start by using KMDF.
You’ll be able to put this together with almost no code. If you tell
KMDF that the driver is a filter you should be able to allow all I/O
operations pass right through the driver.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Thursday, March 23, 2006 10:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question on right way to proceed

A company I’m associated with has a device that interfaces to the scsi
bus and calls itself a processor class device. In the past, the
application program that uses this has enumerated the scsi busses by
successively opening \scsi0 to scsiN and doing a bus scan for the
device. On finding it, the application uses scsi passthru to send and
receive raw scsi packets.

With modern USB adapters this is failing because the adapters don’t name
themselves scsnN devices any more. Attempts by another programmer at
using the SetupDI interfaced to enumerate the scsi busses were
unsuccessful. I don’t kow of this was failure of imagination or
something else going wrong; I’ll be experimenting with that today.

But it seems the right way to go is to install a real driver for this
device. The driver would really do nothing more than identify itself
correctly, have a resolvable name (for the application program) and just
pass the scsi passthru packets through.

Where should I start to make such a driver? Should I expect any
problems in particular to be aware of?

Loren

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

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

3

You can easily make a pass through driver in KMDF if you want all I/O to
get to the PDO. I would say that 90% of the code will be in setup in
your AddDevice routine. Are you going to filter an existing stack or
install on top of a PDO directly w/out any other drivers?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Thursday, March 23, 2006 10:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question on right way to proceed

A company I’m associated with has a device that interfaces to the scsi
bus
and calls itself a processor class device. In the past, the application
program that uses this has enumerated the scsi busses by successively
opening \scsi0 to scsiN and doing a bus scan for the device. On
finding
it, the application uses scsi passthru to send and receive raw scsi
packets.

With modern USB adapters this is failing because the adapters don’t name
themselves scsnN devices any more. Attempts by another programmer at
using
the SetupDI interfaced to enumerate the scsi busses were unsuccessful.
I
don’t kow of this was failure of imagination or something else going
wrong;
I’ll be experimenting with that today.

But it seems the right way to go is to install a real driver for this
device. The driver would really do nothing more than identify itself
correctly, have a resolvable name (for the application program) and just
pass the scsi passthru packets through.

Where should I start to make such a driver? Should I expect any
problems in
particular to be aware of?

Loren

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

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

4

We do something similar. However, we know that the device of our
interest lives on the SAN. Therefore, we use
IOCTL_STORAGE_QUERY_PROPERTY to figure out the bus type and then only
look at the buses of type BusTypeFibre or BusTypeScsi
This allows us to find the device and we can then do pass thru (direct)
to it. We do not need to have a class driver defined for it.

Harish

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-245638-
xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Thursday, March 23, 2006 10:45 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question on right way to proceed

A company I’m associated with has a device that interfaces to the scsi
bus
and calls itself a processor class device. In the past, the
application
program that uses this has enumerated the scsi busses by successively
opening \scsi0 to scsiN and doing a bus scan for the device. On
finding
it, the application uses scsi passthru to send and receive raw scsi
packets.

With modern USB adapters this is failing because the adapters don’t
name
themselves scsnN devices any more. Attempts by another programmer at
using
the SetupDI interfaced to enumerate the scsi busses were unsuccessful.
I
don’t kow of this was failure of imagination or something else going
wrong;
I’ll be experimenting with that today.

But it seems the right way to go is to install a real driver for this
device. The driver would really do nothing more than identify itself
correctly, have a resolvable name (for the application program) and
just
pass the scsi passthru packets through.

Where should I start to make such a driver? Should I expect any
problems
in
particular to be aware of?

Loren

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

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

5

Can you provide a little more detail on why SetupDi* didn’t work for you?
MS storage and USB drivers all identify their device objects with device
interfaces, which can be found very easily with SetupDiGetClassDevs,
provided the function is used properly.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Thursday, March 23, 2006 1:45 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Question on right way to proceed

A company I’m associated with has a device that interfaces to the scsi bus
and calls itself a processor class device. In the past, the application
program that uses this has enumerated the scsi busses by successively
opening \scsi0 to scsiN and doing a bus scan for the device. On finding
it, the application uses scsi passthru to send and receive raw scsi packets.

With modern USB adapters this is failing because the adapters don’t name
themselves scsnN devices any more. Attempts by another programmer at using
the SetupDI interfaced to enumerate the scsi busses were unsuccessful. I
don’t kow of this was failure of imagination or something else going wrong;
I’ll be experimenting with that today.

But it seems the right way to go is to install a real driver for this
device. The driver would really do nothing more than identify itself
correctly, have a resolvable name (for the application program) and just
pass the scsi passthru packets through.

Where should I start to make such a driver? Should I expect any problems in
particular to be aware of?

Loren

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

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

6

> Can you provide a little more detail on why SetupDi* didn’t work for you?

MS storage and USB drivers all identify their device objects with device
interfaces, which can be found very easily with SetupDiGetClassDevs,
provided the function is used properly.

It wasn’t me that did that experiment, so I can’t provide a lot of help.
The other guy claimed that GetClassDevs would enumerate some devices, but
tended to skip right over a lot of devices, including the USB->SCSI
converters of interest. As I say, I don’t know if he set the wrong flags or
what, I’b building a testcase now to see what results I get.

Loren

7

> You could scan the hardware tree through the PNP API for devices with

the right HWID.

Interesting, I didn’t know you could scan for a particular hardware id.
I’ll have to try to track this one down, it seems like the simplest
solution.

You know off the top of your head the name of the appropriate setupdi
function to get the hardware id?

Loren

8

Of course if the USB->SCSI converters of interest are in a different
device class, you will not see them…

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Thursday, March 23, 2006 12:37 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question on right way to proceed

Can you provide a little more detail on why SetupDi* didn’t work for
you?
MS storage and USB drivers all identify their device objects with
device
interfaces, which can be found very easily with SetupDiGetClassDevs,
provided the function is used properly.

It wasn’t me that did that experiment, so I can’t provide a lot of help.
The other guy claimed that GetClassDevs would enumerate some devices,
but
tended to skip right over a lot of devices, including the USB->SCSI
converters of interest. As I say, I don’t know if he set the wrong
flags or
what, I’b building a testcase now to see what results I get.

Loren

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

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

9

Loren Wilton wrote:

>You could scan the hardware tree through the PNP API for devices with
>the right HWID.
>
>

Interesting, I didn’t know you could scan for a particular hardware id.
I’ll have to try to track this one down, it seems like the simplest
solution.

You know off the top of your head the name of the appropriate setupdi
function to get the hardware id?

The answer to this question, as with almost all SetupDi questions, is
“read the devcon source”. It is an incredible treasure trove of
practical usage information on the SetupDi APIs.

In this case, it basically enumerates through all devices of all
classes, fetches the hwid property from the device info, and compares it.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

10

It’s one of the properties of the device node, like the service or the
friendly name.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Thursday, March 23, 2006 12:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question on right way to proceed

You could scan the hardware tree through the PNP API for devices with
the right HWID.

Interesting, I didn’t know you could scan for a particular hardware id.
I’ll have to try to track this one down, it seems like the simplest
solution.

You know off the top of your head the name of the appropriate setupdi
function to get the hardware id?

Loren

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

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