Where should I start on this?

NTDEV
1

I’ve inherited support for a couple of audio processor devices. The new one has an ethernet port and speaks UDP to the host system, and works quite well.

The older units used a SCSI port and claimed to be a Processor device. This was electrically functional, but not well supported by applications. There was no driver for the device, but there was an INF file to register the device as not requiring a driver. Applications would hunt around for the device id string and then do raw scsi IO to the units.

It would be nice to develop a driver to make the old SCSI-connected units look like the newer network-connected units, since there are already a lot of applications that can use the newer units. The command sets aren’t identical between the units, but they are mappable in a driver, so that shouldn’t be a problem.

Now, I somewhat understand the SCSI stack and where I might install a pnp driver that could handle the old units. But I know zip about the networking stuff. Where should I start looking for how to make a scsi-to-network driver for this? I assume I have to make this device look like a network adapter to the network stack, and somehow bind UDP protocol handling to it? But it is a scsi device, so the driver will probably load on the storage stack. Is this a problem?

So, where should I start? What should this animal end up looking like?

Thanks,

Loren

2

AFAICT, You should be able to do this entirely from user-land. You app
could take care of hunting around for the device and sending raw SCSI
commands to it, as previous applications did. You app would also listen
on a port for UDP connections, you app would translate the requests
over the network to SCSI commands to the actual device.

There are numerous tutorials about (TCP, UDP, whatever) networking on
the net (google is your friend).

–

Cliff

On 3-Jan-05, at 10:42 AM, Loren Wilton wrote:

I’ve inherited support for a couple of audio processor devices. The
new one has an ethernet port and speaks UDP to the host system, and
works quite well.

The older units used a SCSI port and claimed to be a Processor device.
This was electrically functional, but not well supported by
applications. There was no driver for the device, but there was an
INF file to register the device as not requiring a driver.
Applications would hunt around for the device id string and then do
raw scsi IO to the units.

It would be nice to develop a driver to make the old SCSI-connected
units look like the newer network-connected units, since there are
already a lot of applications that can use the newer units. The
command sets aren’t identical between the units, but they are mappable
in a driver, so that shouldn’t be a problem.

Now, I somewhat understand the SCSI stack and where I might install a
pnp driver that could handle the old units. But I know zip about the
networking stuff. Where should I start looking for how to make a
scsi-to-network driver for this? I assume I have to make this device
look like a network adapter to the network stack, and somehow bind UDP
protocol handling to it? But it is a scsi device, so the driver will
probably load on the storage stack. Is this a problem?

So, where should I start? What should this animal end up looking like?

Thanks,

Loren

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

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

3

> AFAICT, You should be able to do this entirely from user-land. You app

Duh, thanks! I have absolutely no idea why I didn’t think of that. I *KNOW* how to do that, it doesn’t even take any searching around for documentation!

Loren

4

Hmm. Audio processor. On a SCSI bus. Wow.

I can’t help with the network stuff, I probably know less about that than
you do.

In a sense, you got the SCSI stuff right. If you want to develop a driver
for the SCSI device, it would be a class driver for the SCSI Processor
device. It’s not a really in the storage stack, it’s more like a class
driver for a non-storage device like a printer or scanner.

You don’t mention if there is a driver for the network attached device. Do
the apps just send packets to an IP address?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

xxxxx@lists.osr.com wrote on 01/03/2005 11:42:56 AM:

I’ve inherited support for a couple of audio processor devices. The
new one has an ethernet port and speaks UDP to the host system, and
works quite well.

The older units used a SCSI port and claimed to be a Processor
device. This was electrically functional, but not well supported by
applications. There was no driver for the device, but there was an
INF file to register the device as not requiring a driver.
Applications would hunt around for the device id string and then do
raw scsi IO to the units.

It would be nice to develop a driver to make the old SCSI-connected
units look like the newer network-connected units, since there are
already a lot of applications that can use the newer units. The
command sets aren’t identical between the units, but they are
mappable in a driver, so that shouldn’t be a problem.

Now, I somewhat understand the SCSI stack and where I might install
a pnp driver that could handle the old units. But I know zip about
the networking stuff. Where should I start looking for how to make
a scsi-to-network driver for this? I assume I have to make this
device look like a network adapter to the network stack, and somehow
bind UDP protocol handling to it? But it is a scsi device, so the
driver will probably load on the storage stack. Is this a problem?

So, where should I start? What should this animal end up looking like?

Thanks,

Loren

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

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

5

Perhaps a service might be the right animal for this approach, as it
appears that Loren wants an interposer between existing apps that talk to
the network attached device, and a SCSI attached device.

If you have to start an auxiliary process in order for that to happen,
it’s really a service, so if you write it that way, you’ll probably save
yourself some pain.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

xxxxx@lists.osr.com wrote on 01/03/2005 11:59:31 AM:

AFAICT, You should be able to do this entirely from user-land. You app
could take care of hunting around for the device and sending raw SCSI
commands to it, as previous applications did. You app would also listen
on a port for UDP connections, you app would translate the requests
over the network to SCSI commands to the actual device.

There are numerous tutorials about (TCP, UDP, whatever) networking on
the net (google is your friend).

–

Cliff

On 3-Jan-05, at 10:42 AM, Loren Wilton wrote:

> I’ve inherited support for a couple of audio processor devices. The
> new one has an ethernet port and speaks UDP to the host system, and
> works quite well.
>
> The older units used a SCSI port and claimed to be a Processor device.

> This was electrically functional, but not well supported by
> applications. There was no driver for the device, but there was an
> INF file to register the device as not requiring a driver.
> Applications would hunt around for the device id string and then do
> raw scsi IO to the units.
>
> It would be nice to develop a driver to make the old SCSI-connected
> units look like the newer network-connected units, since there are
> already a lot of applications that can use the newer units. The
> command sets aren’t identical between the units, but they are mappable

> in a driver, so that shouldn’t be a problem.
>
> Now, I somewhat understand the SCSI stack and where I might install a
> pnp driver that could handle the old units. But I know zip about the
> networking stuff. Where should I start looking for how to make a
> scsi-to-network driver for this? I assume I have to make this device
> look like a network adapter to the network stack, and somehow bind UDP

> protocol handling to it? But it is a scsi device, so the driver will
> probably load on the storage stack. Is this a problem?
>
> So, where should I start? What should this animal end up looking
like?
>
> Thanks,
>
> Loren
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@telus.net
> 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@seagate.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

>You don’t mention if there is a driver for the network attached device. Do

the apps just send packets to an IP address?

No, no driver needed. The box speaks a pretty clean UDP protocol and acts as a server (as much as that means in terms of UDP), so applications just open a UDP port to a known port number at some given IP address. And there is a discovery protocol so the apps can hunt down all of the processors on the local network. Actually ends up working fairly well.

Loren

7

I think that you can do all in user mode using SPTI.

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

----- Original Message -----
From: “Loren Wilton”
To: “Windows System Software Devs Interest List”
Sent: Monday, January 03, 2005 9:42 PM
Subject: [ntdev] Where should I start on this?

> I’ve inherited support for a couple of audio processor devices. The new one
has an ethernet port and speaks UDP to the host system, and works quite well.
>
> The older units used a SCSI port and claimed to be a Processor device. This
was electrically functional, but not well supported by applications. There was
no driver for the device, but there was an INF file to register the device as
not requiring a driver. Applications would hunt around for the device id
string and then do raw scsi IO to the units.
>
> It would be nice to develop a driver to make the old SCSI-connected units
look like the newer network-connected units, since there are already a lot of
applications that can use the newer units. The command sets aren’t identical
between the units, but they are mappable in a driver, so that shouldn’t be a
problem.
>
> Now, I somewhat understand the SCSI stack and where I might install a pnp
driver that could handle the old units. But I know zip about the networking
stuff. Where should I start looking for how to make a scsi-to-network driver
for this? I assume I have to make this device look like a network adapter to
the network stack, and somehow bind UDP protocol handling to it? But it is a
scsi device, so the driver will probably load on the storage stack. Is this a
problem?
>
> So, where should I start? What should this animal end up looking like?
>
> Thanks,
>
> Loren
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com