How to send inquiry command to thorugh sd path (i.e. /dev/sda) by using SG_IO ioctl

[Masthan]

Hi All,

Any one og you have any idea on scsi inquiry command ?

I want to send an Inquiry command to a scsi device through sd path (.i.e. /dev/sda or /dev/sdb) by using SG_IO ioctl. Please explain me...


Your help is appreciated

Regards
Masthan

[Sandeepk_1]

Hi Masthan,

You can use the sg_inq command for your purpose.
This utility executes a SCSI INQUIRY command on the given device and interprets the results according to SPC-3 document. The term "standard INQUIRY" refers to a INQUIRY cdb that neither requests a Vital Product Data (VPD) page nor Command Detail information (via the CmdDt bit). Here is the output from a standard INQUIRY. Actually the last entry ("Unit serial number") comes from the VPD page [0x80] of the same name if it is available. Older SCSI devices often put a serial number in a vendor specific area of a standard INQUIRY response (typically between bytes 36 and 55 inclusive).
$ sg_inq /dev/sda

VPD pages are available from an INQUIRY, either in hex (e.g. with the option '-p=') or, in some cases, in decoded form. The importance of VPD pages is illustrated by two being made mandatory in latter versions of SPC-3: Supported VPD pages [0x0] and the Device Identification page [0x83]. Several VPD pages are now decoded. The "Supported VPD pages" page [0x0] is decoded when the '-e' option is given [without the '-p=' option] (sg3_utils >= v1.08). The Device Identification page [0x83] is decoded when the '-i' option is given (sg3_utils >= v1.07). The Extended INQUIRY page [0x86] is decoded when the '-x' option is given (sg3_utils >= v1.09). The SCSI Ports page [0x88] is decoded when the '-s' option is given (sg3_utils >= v1.11). The EMC (i.e. vendor) specific Unit Path Report page [0xc0] is decoded when the '-P' option is given (sg3_utils >= v1.09). Here is an example of the output from requesting the "Supported VPD pages" page:
$ sg_inq -e /dev/sg1

The '-c' and '-cl' options permit supported SCSI commands to be listed by using the CmdDt bit in an INQUIRY request. However SPC-3 has obsoleted this feature and introduced the new REPORT SUPPORTED OPERATION CODES SCSI command (see the sg_opcodes utility introduced in sg3_utils version 1.07). Not many SCSI devices support the new command yet.

In sg3_utils version 1.08 a '-d' switch has been added to decode version descriptors. A standard INQUIRY response optionally contains up to 8 of these. For example a SCSI disk might have 4 version descriptors: SAM-2, SPC-2, SBC and SPI-4. SAM-2 is general architectural compliance, SPC-2 for SCSI primary (i.e. common) commands supported, SBC for SCSI block command set and SPI-4 indicates Ultra 320 support. Here is an example of the version descriptors on a disk:
$ sg_inq -d /dev/sdb

You can also use the scsi_inquiry command
This program demonstrates the use of the SCSI_IOCTL_SEND_COMMAND ioctl to send a SCSI INQUIRY command. That ioctl() is supported by the SCSI sub system mid level and so is common to all sd, sr, st (osst) and sg devices. In sg3_utils this utility has been moved to the archive directory

[Masthan]

Hi Sandeep,

Thanks for quick and long reply.
But that is not what I am looking I want to implement use own scsi inquiry command (by using SG_IO ioclts through sd path).
What My application does is,

1) opens the sd device
2) send scsi inquiry command ioctl(fd, SG_IO)
3) report scsi inquiry data
4) close(fd)

I am blokcing at step2...
Can you explain me how to send SG_IO ioctl ?

-Mashtan

[Matti_Kurkela]

You must first create and populate a "struct sg_io_hdr".

You must also create a SCSI command block for the Inquiry command and use the cmdp field of the struct sg_io_hdr to point to it. The cmd_len field should contain the length of the command block.

You must also prepare some memory for the Inquiry response. The pointer to the memory area goes to the dxferp field of the struct sg_io_hdr, and the available length of that area goes to the dxfer_len field. The dxfer_direction field should be set to DXFER_FROM_DEV.

The "interface_id" field of the sg_io_hdr must be set to 'S'. This is needed to guard against an obsolete form of this ioctl.

See this for an example:
http://sg.torque.net/sg/sg_io.html#mozTocId568229

The Linux SCSI Generic HOWTO has detailed documentation about the different fields of the sg_io_hdr structure:
http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/index.html

By the way... did my previous reply to you help at all?
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1106770

If this answer does not help, please give us more detail on what is going wrong.

[Florian Heigl (new acc)]

There's a CAM-like implementation for linux, is that what you're looking for?

Like, setting modepages and such stuff? If yes, I'll dig through my bookmarks :)

[Masthan]

Hi,

Thanks for your quick reply. With your answer I am a little but comfort but I feel it is good if you explain it with an example. Why because all the examles @ sg3 utils are talking about only sg path no example is taking sd path input. I will try with your options, I will let you know if I have any issues.

-Masthan

[Masthan]

Hi,

Thanks for your quick reply. With your answer I am a little bit comfort but I feel it is good if you explain it with an example. Why because all the examles @ sg3 utils are talking about only sg path no example is taking sd path input. I will try with your options, I will let you know if I have any issues.

-Masthan

[Florian Heigl (new acc)]

As far as I understand linux scsi, 'sg' means scsi generic, whereas 'sd' is a scsi disk; that means different drivers, and a disk driver doesn't really need to include an interface for lowlevel scsi commands; that's all stuffed into 'sg', so that should be ok.

(or maybe I'm dead wrong)

The thing in my bookmarks was "scu", the scsi command utility, which is a bit dated, but has nice features.
http://home.comcast.net/~SCSIguy/SCSI_FAQ/RMiller_Tools/scu.html

florian

[Matti_Kurkela]

Linux used to have "sg" as a separate interface, but hot-plugging devices made that interface awkward to use (no way to relate which generic device maps to which disk/tape/cdrom/whatever device).

The problem was the most obvious with the CD/DVD recorders (especially USB/Firewire-connected ones): the users were confused by having one interface for reading the media normally and another for burning. As a result, the normal disk/tape/cdrom device nodes will now (in kernel series 2.6.x and above) accept the SG_IO ioctls too.

If you don't have root privileges, the kernel will sanitize the SG_IO requests so that only the known-harmless requests are allowed. To upgrade the firmware of your disk, you'll still need to be root.

[Masthan]

Hi All,

You people are deviating that actual question. What I am expecting and what to know from you is,

For inquiry ioctl, how sg_io_hdr structure definition will vary/differ for sg devices and for sd devices.

The following snippet talks about the inquiry ioctl for sg devices by using SG_IO and sg_io_hdr

unsigned char sense_b[32];
unsigned char turCmbBlk[] = {TUR_CMD, 0, 0, 0, 0, 0};
struct sg_io_hdr io_hdr;

memset(&io_hdr, 0, sizeof(struct sg_io_hdr));
io_hdr.interface_id = 'S';
io_hdr.cmd_len = sizeof(turCmbBlk);
io_hdr.mx_sb_len = sizeof(sense_b);
io_hdr.dxfer_direction = SG_DXFER_NONE;
io_hdr.cmdp = turCmbBlk;
io_hdr.sbp = sense_b;
io_hdr.timeout = DEF_TIMEOUT;

if (ioctl(fd, SG_IO, &io_hdr) < 0) {


Now I want to know how the above sg_io_hdr definiton will vary for sd devices ? Can you redefine the above structure so that it will work for sd devices ?

[Florian Heigl (new acc)]

My point was that you're not supposed to inquire sd, but sg.

[Masthan]

Why Can't we inquriy through sd path, So many documents clealy saying that on 2.6 kernels SG_IO ioctls supports both sg and sd drivers but now you are saying that use only sg driver for inquiry. Why can't we use sd driver for inquiry ?