We have a tentative project coming up where the customer’s software uses SCSI commands to talk to their device (v. old software). Their software opens the SCSI device and uses SPTI to send/receive commands /data.
They are looking to move away from SCSI cards towards a USB-based solution but are, for various reasons, unable to make many/any changes to their software.
We already ship a USB solution, with a UMDF driver, for other target devices and are considering a variant of this for the project. The USB variant is a box that would receive USB commands and then talk SCSI to the target device.
Is is possible to create a USB driver of some that could be made to appear as a SCSI device and accept SPTI commands, and then pass them to the USB device and then return the results back up to the software?
Vague, I know, for which I apologise, but I have very little real information at the moment.
Thanks,
Peter Young
Xitron Europe
SPTI just uses IOCTLs… Just implement the same IOCTLs and translate the embedded CDBs.
Sounds straight forward to me…
Peter
OSR
@OSRDrivers
Remember that SPTI may be using an embedded pointer to the buffer, which needs to be handled in the context of the calling process.
Are there any sample SCSI Filter drivers available that I can look at as examples.
Given the potential inability of the client to be able to change their code, I need my solution to appear as a SCSI device even though it will translate the IOCTLs and send to my USB device. Is this even possible?
Then create a virtual storport driver and send the USB commands from it to
the actual device.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@vgieurope.com
Sent: Friday, August 08, 2014 11:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Advice on a USB driver for a SCSI device!
Are there any sample SCSI Filter drivers available that I can look at as
examples.
Given the potential inability of the client to be able to change their code,
I need my solution to appear as a SCSI device even though it will translate
the IOCTLs and send to my USB device. Is this even possible?
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
What does “appear as a SCSI device” mean to you?
There are lots of SCSI devices… disks, tapes, CDs, DVDs… there are even SCSI Printers. They all look like the devices that they are. For example, SCSI Printers look like printers to the system. They just happen to be ATTACHED via a SCSI bus.
Peter
OSR
@OSRDrivers
@Peter:
It depends on how the application locates the device. Is it opening \.\Scsi or is enumerating SCSI_INTERFACE_GUID, or anything else.
The aplication is using SPTI, which would be easy to handle in an arbitrary driver. The unknown part is the enumeration.
Agree. That’s why I’m asking the OP what “appear as a SCSI device” means to them.
Even in an arbitrary driver it should be easy to handle the Device Interface GUID or name or whatever…
Unless there’s some secret mystic sauce that you can’t get otherwise, creating a Virtual StorPort Miniport just *can’t* be a good idea. That would take the project from the realm of “write a simple KMDF driver” to “seriously annoying” in one big step.
Peter
OSR
@OSRDrivers
Alex, as far as I am aware the customer source code currently uses the \.\Scsi style of opening the device and the DeviceIocl calls using the STPI ioctls to send/receive the SCSI commands/responses.
The main data flow will be data from the front-end to the target imagesetter.
The USB box we are proposing to use will be a variant of a product we already ship to drive a variety of imagsetters. We already have a UMDF driver for this.
This has on-board firmware that we can load when the device is plugged in to customise it for the various imagesetters we support via this mechanism.
No problem then, right? Just create an ordinary WDF drier with devices pointed to by symbolic link names “\Global\Scsi” - Interpret the SPTI in your driver. As Mr. Grig correctly pointed out, if those SPTI commands have embedded pointers you’ll need to handle this in your driver’s EvtInCallerContext Event Processing Callback.
Peter
OSR
@OSRDrivers
In another thread on this site someone asked about what happens if you try to generate a symbolic link when that link already exists, but there did not seem to be a clear answer.
If I am going to create a symbolic link to my device what do I do if the name I want to use is already present. My current hope/thinking is that the IWDFDevice::CreateSymbolicLink() call will return ERROR_ALREADY_EXISTS and I can then try with another name (increment from Scsi0 to Scsi1, etc) until I find one that works.
The thread unclear if the call actually did return ERROR_ALREADY_EXISTS in that particular scenario.
It also seemed to imply that having failed with Scsi0, it succeeded with Scsi1, but had broken the symbolic link for Scsi0 to the device that had originally created it, which for obvious reasons is not an acceptable state of affairs.
Can anyone clarify the situation?
Thanks,
Pete Young