IOCTL_SCSI_GET_ADDRESS on SAS devices?
in [Device Drivers]
|
Prev: Gothica download MP3
Next: WDF API vs WDM API
From: Peter Karlsson on 9 Apr 2008 09:19 Hi! I have been given the task of porting an old SCSI application to support SAS. The underlying libraries are really old, as they were originally written to use ASPI for DOS, later ported to ASPI for Win16, then to ASPI for Win32, and through the aspiemu.c that was published in Dr. Drobb's in 1997, to use SPTI. The libraries still think they are using ASPI (through SendASPI32Command) to a device identified by a host adapter number, a device number and a LUN. Now, how does SAS enter in the equation? To map the SCSI id/LUN back to a device name, the aspiemu.c uses IOCTL_SCSI_GET_ADDRESS to find the device node that corresponds to the SCSI id I give it. Is it at all possible to use this scheme for SAS devices, and if so, what kind of SCSI id should I hand it? Any tips and pointers in the right direction would be highly appreciated. -- \\// Peter Karlsson - peter.karlsson(a)domain.in.header
From: Alexander Grigoriev on 9 Apr 2008 10:57 SAS is just a transport (as much as "old" SCSI, iSCSI, FCP, etc). SCSI_GET_ADDRESS is handled on the higher layer. Properly written application should not care what transport is used. It should even be able to work with ATAPI devices. No "porting" should be required. "Peter Karlsson" <reply.to.newsgroup(a)tandbergdata.com> wrote in message news:op.t9chyb1hx32khr(a)hammas.tdata.no... > Hi! > > I have been given the task of porting an old SCSI application to support > SAS. The underlying libraries are really old, as they were originally > written to use ASPI for DOS, later ported to ASPI for Win16, then to ASPI > for Win32, and through the aspiemu.c that was published in Dr. Drobb's in > 1997, to use SPTI. > > The libraries still think they are using ASPI (through SendASPI32Command) > to a device identified by a host adapter number, a device number and a > LUN. > > > Now, how does SAS enter in the equation? To map the SCSI id/LUN back to a > device name, the aspiemu.c uses IOCTL_SCSI_GET_ADDRESS to find the device > node that corresponds to the SCSI id I give it. Is it at all possible to > use this scheme for SAS devices, and if so, what kind of SCSI id should I > hand it? > > Any tips and pointers in the right direction would be highly appreciated. > > -- > \\// Peter Karlsson - peter.karlsson(a)domain.in.header
From: KenH on 9 Apr 2008 11:06 Hi, I tried the MSDN getaddr.exe sample code a couple of weeks ago and found it still work. It uses IOCTL_SCSI_GET_ADDRESS with the symbolic name such as PhysicalDrive7 to get its Port/Bus/Target/Lun numbers alright. If you want to get its symbolic name from the SCSI address (port/bus/target/lun) then it couldn't. You may want to search getaddr.exe in MSDN and see it by yourself. BTW, if you figure out using SCSI address to get the symbolic name please post it, I need that solution too. Currently I try to loop through all the PhysicalDriveX and find the match. But I don't really like the solution. Ken "Peter Karlsson" wrote: > Hi! > > I have been given the task of porting an old SCSI application to support > SAS. The underlying libraries are really old, as they were originally > written to use ASPI for DOS, later ported to ASPI for Win16, then to ASPI > for Win32, and through the aspiemu.c that was published in Dr. Drobb's in > 1997, to use SPTI. > > The libraries still think they are using ASPI (through SendASPI32Command) > to a device identified by a host adapter number, a device number and a LUN. > > > Now, how does SAS enter in the equation? To map the SCSI id/LUN back to a > device name, the aspiemu.c uses IOCTL_SCSI_GET_ADDRESS to find the device > node that corresponds to the SCSI id I give it. Is it at all possible to > use this scheme for SAS devices, and if so, what kind of SCSI id should I > hand it? > > Any tips and pointers in the right direction would be highly appreciated. > > -- > \\// Peter Karlsson - peter.karlsson(a)domain.in.header >
From: Peter Karlsson on 9 Apr 2008 11:10 Alexander Grigoriev <alegr(a)earthlink.net>: > SAS is just a transport (as much as "old" SCSI, iSCSI, FCP, etc). > SCSI_GET_ADDRESS is handled on the higher layer. Properly written > application should not care what transport is used. It should even be > able to work with ATAPI devices. No "porting" should be required. I.e, the system will assign sequential IDs to the devices, which I should be able to use in my application? I cannot get this to work at the moment, but it might be an artifact of the ASPIEMU code[1]. It tries to emulate ASPI's addressing by walking the list of devices retrieved from the QueryDosDevice() API and performing IOCTL_SCSI_GET_ADDRESS on every single device to find the device I am looking for. I tried writing a small application that would do the same, walk the QueryDosDevice() tree and look up all the devices, but I cannot get it to find the device I am looking for. Perhaps it only works for devices that there is an actual device driver installed for? Or is there another way to enumerate SCSI devices (only), including ones not claimed by drivers? [1] aspiemu.zip from ftp://66.77.27.238/sourcecode/ddj/1997/9712.zip -- \\// Peter Karlsson - peter.karlsson(a)domain.in.header
From: Peter Karlsson on 9 Apr 2008 11:15
KenH <KenHwang(a)newsgroup.nospam>: > It uses IOCTL_SCSI_GET_ADDRESS with the symbolic name such as > PhysicalDrive7 to get its Port/Bus/Target/Lun numbers alright. If you > want to get its symbolic name from the SCSI address > (port/bus/target/lun) then it couldn't. You may want to search > getaddr.exe in MSDN and see it by yourself. Hmm, I will have to have a look at that tomorrow. Thanks for the pointer. > Currently I try to loop through all the PhysicalDriveX and find the > match. But I don't really like the solution. That seems to be the same as the aspiemu code is doing, although it iterates over all devices (i.e, the entire list of devices from QueryDosDevice() with NULL as its first parameter). -- \\// Peter Karlsson - peter.karlsson(a)domain.in.header |