[PATCH] Print SCSI Inquiry data more compactly

[PATCH] Print SCSI Inquiry data more compactly

[Matthew Wilcox]

print_inquiry is rather verbose, both in implementation and in output.
This patch reduces the output from two lines to one and reduces the
implementation to a single printk.

Sample output:
  Vendor: HP 18.2G  Model: ATLAS10K3_18_SCA  Rev: HP05
  Type:   Direct-Access                      ANSI SCSI revision: 02

becomes:

scsi 2:0:1:0: Device: HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 02               

Signed-off-by: Matthew Wilcox <matthew@wil.cx>

Index: drivers/scsi/scsi_scan.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/scsi/scsi_scan.c,v
retrieving revision 1.41
diff -u -p -r1.41 scsi_scan.c
--- drivers/scsi/scsi_scan.c	29 May 2006 02:51:18 -0000	1.41
+++ drivers/scsi/scsi_scan.c	20 Jun 2006 22:12:44 -0000
@@ -186,59 +186,6 @@ static void scsi_unlock_floptical(struct
 }
 
 /**
- * print_inquiry - printk the inquiry information
- * @inq_result:	printk this SCSI INQUIRY
- *
- * Description:
- *     printk the vendor, model, and other information found in the
- *     INQUIRY data in @inq_result.
- *
- * Notes:
- *     Remove this, and replace with a hotplug event that logs any
- *     relevant information.
- **/
-static void print_inquiry(unsigned char *inq_result)
-{
-	int i;
-
-	printk(KERN_NOTICE "  Vendor: ");
-	for (i = 8; i < 16; i++)
-		if (inq_result[i] >= 0x20 && i < inq_result[4] + 5)
-			printk("%c", inq_result[i]);
-		else
-			printk(" ");
-
-	printk("  Model: ");
-	for (i = 16; i < 32; i++)
-		if (inq_result[i] >= 0x20 && i < inq_result[4] + 5)
-			printk("%c", inq_result[i]);
-		else
-			printk(" ");
-
-	printk("  Rev: ");
-	for (i = 32; i < 36; i++)
-		if (inq_result[i] >= 0x20 && i < inq_result[4] + 5)
-			printk("%c", inq_result[i]);
-		else
-			printk(" ");
-
-	printk("\n");
-
-	i = inq_result[0] & 0x1f;
-
-	printk(KERN_NOTICE "  Type:   %s ",
-	       i <
-	       MAX_SCSI_DEVICE_CODE ? scsi_device_types[i] :
-	       "Unknown          ");
-	printk("                 ANSI SCSI revision: %02x",
-	       inq_result[2] & 0x07);
-	if ((inq_result[2] & 0x07) == 1 && (inq_result[3] & 0x0f) == 1)
-		printk(" CCS\n");
-	else
-		printk("\n");
-}
-
-/**
  * scsi_alloc_sdev - allocate and setup a scsi_Device
  *
  * Description:
@@ -706,9 +653,8 @@ static int scsi_add_lun(struct scsi_devi
 	if (*bflags & BLIST_ISROM) {
 		/*
 		 * It would be better to modify sdev->type, and set
-		 * sdev->removable, but then the print_inquiry() output
-		 * would not show TYPE_ROM; if print_inquiry() is removed
-		 * the issue goes away.
+		 * sdev->removable; this can now be done since
+		 * print_inquiry has gone away.
 		 */
 		inq_result[0] = TYPE_ROM;
 		inq_result[1] |= 0x80;	/* removable */
@@ -737,7 +683,10 @@ static int scsi_add_lun(struct scsi_devi
 		printk(KERN_INFO "scsi: unknown device type %d\n", sdev->type);
 	}
 
-	print_inquiry(inq_result);
+	sdev_printk(KERN_NOTICE "scsi", sdev, "Device: %.8s %.16s %.4s "
+			"ANSI ver: %02x%s\n", sdev->vendor, sdev->model,
+			sdev->rev, inq_result[2] & 0x07,
+			(inq_result[3] & 0x0f) == 1 ? " CCS" : "");
 
 	/*
 	 * For a peripheral qualifier (PQ) value of 1 (001b), the SCSI

Re: [PATCH] Print SCSI Inquiry data more compactly

[Douglas Gilbert]

Matthew Wilcox wrote:
> print_inquiry is rather verbose, both in implementation and in output.
> This patch reduces the output from two lines to one and reduces the
> implementation to a single printk.
> 
> Sample output:
>   Vendor: HP 18.2G  Model: ATLAS10K3_18_SCA  Rev: HP05
>   Type:   Direct-Access                      ANSI SCSI revision: 02
> 
> becomes:
> 
> scsi 2:0:1:0: Device: HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 02               

The peripheral device type is useful information, especially
when it is other than "Direct Access".

Doug Gilbert

RE: [PATCH] Print SCSI Inquiry data more compactly

[Salyzyn, Mark]

What about:

    scsi 2:0:1:0: Device: DASD HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver:
02

Or is such SCSI nomenclature like DASD falling from grace?

Sincerely -- Mark Salyzyn

Douglas Gilbert writes:

> > Sample output:
> >   Vendor: HP 18.2G  Model: ATLAS10K3_18_SCA  Rev: HP05
> >   Type:   Direct-Access                      ANSI SCSI revision: 02
> > 
> > becomes:
> > 
> > scsi 2:0:1:0: Device: HP 18.2G ATLAS10K3_18_SCA HP05 ANSI 
> ver: 02               
> 
> The peripheral device type is useful information, especially
> when it is other than "Direct Access".

Re: [PATCH] Print SCSI Inquiry data more compactly

[Matthew Wilcox]

On Wed, Jun 21, 2006 at 10:50:55AM -0400, Douglas Gilbert wrote:
> The peripheral device type is useful information, especially
> when it is other than "Direct Access".

*sigh*.  I wish you'd said that during the first iteration of the patch
;-P

How's this:

scsi 2:0:1:0: Direct-Access     HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 02 

I'll separate out the patches in a moment ... the first patch is a good
separate cleanup patch anyway.

Re: [PATCH] Print SCSI Inquiry data more compactly

[Philip R. Auld]

Hi,

Rumor has it that on Wed, Jun 21, 2006 at 11:42:53AM -0400 Salyzyn, Mark said:
> What about:
> 
>     scsi 2:0:1:0: Device: DASD HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver:
> 02

Parsing this, (and the Matt's earlier version), there are 5 tokens
there in the middle for 4 fields. How does one know what the vendor
string is for example?

Commas maybe?

 scsi 2:0:1:0: Device: DASD, HP 18.2G, ATLAS10K3_18_SCA, HP05, ANSI ver: 02


Cheers,

Phil


> 
> Or is such SCSI nomenclature like DASD falling from grace?
> 
> Sincerely -- Mark Salyzyn
> 
> Douglas Gilbert writes:
> 
> > > Sample output:
> > >   Vendor: HP 18.2G  Model: ATLAS10K3_18_SCA  Rev: HP05
> > >   Type:   Direct-Access                      ANSI SCSI revision: 02
> > > 
> > > becomes:
> > > 
> > > scsi 2:0:1:0: Device: HP 18.2G ATLAS10K3_18_SCA HP05 ANSI 
> > ver: 02               
> > 
> > The peripheral device type is useful information, especially
> > when it is other than "Direct Access".
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

Re: [PATCH] Print SCSI Inquiry data more compactly

[Matthew Wilcox]

On Wed, Jun 21, 2006 at 12:41:50PM -0400, Philip R. Auld wrote:
> >     scsi 2:0:1:0: Device: DASD HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 02
> 
> Parsing this, (and the Matt's earlier version), there are 5 tokens
> there in the middle for 4 fields. How does one know what the vendor
> string is for example?

1) This is not for parsing, it's informational for users.  Do tools
really still parse through /var/log/dmesg?

2) This information is available other ways, such as through sysfs and
procfs.

3) I know it's not obvious from the above example (damn HP firmware),
but these are actually fixed-size fields.  The first is 8 bytes, "HP 18.2G"
the second 16 bytes are "ATLAS10K3_18_SCA", the third is "HP05" and then
the ANSI ver is at the end.

Re: [PATCH] Print SCSI Inquiry data more compactly

[Eddie Williams]

Do you need the labels?  How about
scsi 2:0:1:0:DASD:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:

This keeps it short.  For those that are probably looking at this data
the labels are not needed anyway.  It is easy to parse if someone wants.
I used "DASD" just because that is what was referenced before.  I think
I would prefer the number or "direct access" but either way I would not
lose any sleep.

Eddie
On Wed, 2006-06-21 at 10:50 -0600, Matthew Wilcox wrote:
> On Wed, Jun 21, 2006 at 12:41:50PM -0400, Philip R. Auld wrote:
> > >     scsi 2:0:1:0: Device: DASD HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 02
> > 
> > Parsing this, (and the Matt's earlier version), there are 5 tokens
> > there in the middle for 4 fields. How does one know what the vendor
> > string is for example?
> 
> 1) This is not for parsing, it's informational for users.  Do tools
> really still parse through /var/log/dmesg?
> 
> 2) This information is available other ways, such as through sysfs and
> procfs.
> 
> 3) I know it's not obvious from the above example (damn HP firmware),
> but these are actually fixed-size fields.  The first is 8 bytes, "HP 18.2G"
> the second 16 bytes are "ATLAS10K3_18_SCA", the third is "HP05" and then
> the ANSI ver is at the end.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Print SCSI Inquiry data more compactly

[James Smart]

I agree with Eddie's points, with another small recommendation:

scsi <2:0:1:0> x00:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:

where x00 is byte 1 of the inquiry data - device type and qualifier.
Clarifies the H:C:T:L as well.

-- james

Eddie Williams wrote:
> Do you need the labels?  How about
> scsi 2:0:1:0:DASD:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:
> 
> This keeps it short.  For those that are probably looking at this data
> the labels are not needed anyway.  It is easy to parse if someone wants.
> I used "DASD" just because that is what was referenced before.  I think
> I would prefer the number or "direct access" but either way I would not
> lose any sleep.
> 
> Eddie
> On Wed, 2006-06-21 at 10:50 -0600, Matthew Wilcox wrote:
>> On Wed, Jun 21, 2006 at 12:41:50PM -0400, Philip R. Auld wrote:
>>>>     scsi 2:0:1:0: Device: DASD HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 02
>>> Parsing this, (and the Matt's earlier version), there are 5 tokens
>>> there in the middle for 4 fields. How does one know what the vendor
>>> string is for example?
>> 1) This is not for parsing, it's informational for users.  Do tools
>> really still parse through /var/log/dmesg?
>>
>> 2) This information is available other ways, such as through sysfs and
>> procfs.
>>
>> 3) I know it's not obvious from the above example (damn HP firmware),
>> but these are actually fixed-size fields.  The first is 8 bytes, "HP 18.2G"
>> the second 16 bytes are "ATLAS10K3_18_SCA", the third is "HP05" and then
>> the ANSI ver is at the end.
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] Print SCSI Inquiry data more compactly

[Matthew Wilcox]

On Wed, Jun 21, 2006 at 01:18:43PM -0400, James Smart wrote:
> I agree with Eddie's points, with another small recommendation:
> 
> scsi <2:0:1:0> x00:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:

If you want to get brackets around the 2:0:1:0, you need to talk to
jejb about getting sdev_printk changed.

> where x00 is byte 1 of the inquiry data - device type and qualifier.
> Clarifies the H:C:T:L as well.
> 
> Eddie Williams wrote:
> >Do you need the labels?  How about
> >scsi 2:0:1:0:DASD:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:
> >
> >This keeps it short.  For those that are probably looking at this data
> >the labels are not needed anyway.  It is easy to parse if someone wants.
> >I used "DASD" just because that is what was referenced before.  I think
> >I would prefer the number or "direct access" but either way I would not
> >lose any sleep.

I used scsi_device_type to get the string, so "Direct Access" it is.

Worst case, we get:

scsi 2:0:1:0: Direct-Access     HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 01 CCS

so we're out of room unless we do one or both of:
 - ditch the "ANSI ver:"
 - print the scsi_level instead of "01 CCS"

Using colons instead of spaces to improve parsing is misleading at best;
there's nothing to stop vendors putting colons in their descriptions.
And as I said earlier, there's no need to parse this data anyway.

So we could do:

scsi 2:0:1:0: Direct-Access     xAB HP 18.2G ATLAS10K3_18_SCA HP05 Level: 03

if we really want to see the PQ.  We could even just print the PQ:

scsi 2:0:1:0: Direct-Access     7 HP 18.2G ATLAS10K3_18_SCA HP05 Level: 03

clocking in at a svelte 74 columns.

Re: [PATCH] Print SCSI Inquiry data more compactly

[Philip R. Auld]

Rumor has it that on Wed, Jun 21, 2006 at 10:50:57AM -0600 Matthew Wilcox said:
> On Wed, Jun 21, 2006 at 12:41:50PM -0400, Philip R. Auld wrote:
> > >     scsi 2:0:1:0: Device: DASD HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 02
> > 
> > Parsing this, (and the Matt's earlier version), there are 5 tokens
> > there in the middle for 4 fields. How does one know what the vendor
> > string is for example?
> 
> 1) This is not for parsing, it's informational for users.  Do tools
> really still parse through /var/log/dmesg?
> 

You don't read var/log/dmesgs when you are looking at a scsi issue?
I really meant eye ball parsing mostly.


> 2) This information is available other ways, such as through sysfs and
> procfs.

Why put it here at all then? ;)

> 
> 3) I know it's not obvious from the above example (damn HP firmware),
> but these are actually fixed-size fields.  The first is 8 bytes, "HP 18.2G"
> the second 16 bytes are "ATLAS10K3_18_SCA", the third is "HP05" and then
> the ANSI ver is at the end.

I know they're fixed size fields. I'm not good at counting spaces 
that's why I offered the suggestion of some sort of field sep character.

I wouldn't have thought about it if you didn't use an example with
white spaces :)


Cheers,

Phil


-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

Re: [PATCH] Print SCSI Inquiry data more compactly

[Stefan Richter]

Matthew Wilcox wrote:
> On Wed, Jun 21, 2006 at 01:18:43PM -0400, James Smart wrote:
>>scsi <2:0:1:0> x00:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:
>>Eddie Williams wrote:
>>>scsi 2:0:1:0:DASD:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:
> scsi 2:0:1:0: Direct-Access     HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 01 CCS
> scsi 2:0:1:0: Direct-Access     xAB HP 18.2G ATLAS10K3_18_SCA HP05 Level: 03
> scsi 2:0:1:0: Direct-Access     7 HP 18.2G ATLAS10K3_18_SCA HP05 Level: 03

All of these hurt eyes. What is wrong with the current two-line format?

One line too many? What about silencing protocol drivers first? sd puts 
out a lot of lines right after those inquiry data. What's more, sd is 
forced by some upper layer to go through the initialization twice, 
therefore sd sees fit to print its stuff out twice. This is where I see 
potential to reduce log noise.

Also keep in mind, the inquiry data in the syslog has been a source for 
users to feed the parameter scsi_mod.dev_flags. I.e. keep the vendor and 
model strings distinguishable.

And a beautiful layout of syslog messages is good for the mental peace 
of users.

Highly cryptic log messages on the other hand are about as valuable as 
_no_ log messages at all. The lines I quoted above are not far from 
white noise.

Again, what exactly is the gain from one log line less? The size of 
syslog files is taken care of by logrotate + gzip.

End of rant. :-)
-- 
Stefan Richter
-=====-=-==- -==- =-=-=
http://arcgraph.de/sr/

Re: [PATCH] Print SCSI Inquiry data more compactly

[Matthew Wilcox]

On Wed, Jun 21, 2006 at 08:04:36PM +0200, Stefan Richter wrote:
> Matthew Wilcox wrote:
> >On Wed, Jun 21, 2006 at 01:18:43PM -0400, James Smart wrote:
> >>scsi <2:0:1:0> x00:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:
> >>Eddie Williams wrote:
> >>>scsi 2:0:1:0:DASD:HP 18.2G:ATLAS10K3_18_SCA:HP05:02:
> >scsi 2:0:1:0: Direct-Access     HP 18.2G ATLAS10K3_18_SCA HP05 ANSI ver: 
> >01 CCS
> >scsi 2:0:1:0: Direct-Access     xAB HP 18.2G ATLAS10K3_18_SCA HP05 Level: 
> >03
> >scsi 2:0:1:0: Direct-Access     7 HP 18.2G ATLAS10K3_18_SCA HP05 Level: 03
> 
> All of these hurt eyes. What is wrong with the current two-line format?

Several things.  The way that it's printed means that simultaneous scans
lead to the output getting garbled.  Also, when doing simultaneous scans,
it's no longer clear (was it ever?) which device a particular scan message
belongs to.  That argues for attaching the scsi bus ID to the printk, and
making it all one line, and as atomic as possible.  James tells me that
having the PQ number included helps determine problems with multipathing.

> One line too many? What about silencing protocol drivers first? sd puts 
> out a lot of lines right after those inquiry data. What's more, sd is 
> forced by some upper layer to go through the initialization twice, 
> therefore sd sees fit to print its stuff out twice. This is where I see 
> potential to reduce log noise.

There's a lot of places SCSI is too verbose.  I intend to address all of
them eventually; having hundreds of SCSI devices is really no fun right
now.  That cause isn't helped by people placing spurious roadblocks in
the way.

> Highly cryptic log messages on the other hand are about as valuable as 
> _no_ log messages at all. The lines I quoted above are not far from 
> white noise.

You're exaggerating.  BTW, here's what a line would look like from sbp2 ...

scsi 9:0:0:0: CD-ROM            MATSHITA  UJDA730 DVD/CDRW  1.00 Level: 0 

btw, I've always found that "CD-ROM" a little confusing; considering
that SPC4 says "CD/DVD device", any objections to changing that string
to say "CD/DVD" instead of "CD-ROM"?

Re: [PATCH] Print SCSI Inquiry data more compactly

[Stefan Richter]

Philip R. Auld wrote:
> I know they're fixed size fields. I'm not good at counting spaces 
> that's why I offered the suggestion of some sort of field sep character.

Matthew, what about | as separator? Or is it used in ROMs too?
-- 
Stefan Richter
-=====-=-==- -==- =-==-
http://arcgraph.de/sr/

Re: [PATCH] Print SCSI Inquiry data more compactly

[Matthew Wilcox]

On Thu, Jun 22, 2006 at 12:14:22AM +0200, Stefan Richter wrote:
> Philip R. Auld wrote:
> >I know they're fixed size fields. I'm not good at counting spaces 
> >that's why I offered the suggestion of some sort of field sep character.
> 
> Matthew, what about | as separator? Or is it used in ROMs too?

It's allowed to use anything in the range 0x20 to 0x7e.  See SPC 4,
section 4.4.1.  To be honest, I think separating it with anything other
than space is a bad idea; it makes it look more like it's encoded than
an informational string for the user.

Re: [PATCH] Print SCSI Inquiry data more compactly

[Stefan Richter]

Matthew Wilcox wrote:
> On Wed, Jun 21, 2006 at 08:04:36PM +0200, Stefan Richter wrote:
>> What is wrong with the current two-line format?
> 
> Several things.  The way that it's printed means that simultaneous scans
> lead to the output getting garbled.

That's true, but it could be implemented as an atomic operation with 
multiple printks nonetheless. However you are right, layout should not 
be a reason to add locks. Make it one printk, but please keep it 
readable. The inquiry printout is one of the few that people actually 
care for.

> You're exaggerating.

On purpose. :-)

> BTW, here's what a line would look like from sbp2 ...
> 
> scsi 9:0:0:0: CD-ROM            MATSHITA  UJDA730 DVD/CDRW  1.00 Level: 0 

Here is another SBP-2 device:
    Vendor: ST340083  Model: 2A                Rev: 3.01
    Type:   Direct-Access-RBC                  ANSI SCSI revision: 04

This may be misleading if "Vendor:" and "Model:" prefixes are stripped.

> btw, I've always found that "CD-ROM" a little confusing; considering
> that SPC4 says "CD/DVD device", any objections to changing that string
> to say "CD/DVD" instead of "CD-ROM"?

Seems reasonable.
-- 
Stefan Richter
-=====-=-==- -==- =-==-
http://arcgraph.de/sr/

Re: [PATCH] Print SCSI Inquiry data more compactly

[Douglas Gilbert]

Stefan Richter wrote:
> Matthew Wilcox wrote:
> 
>> On Wed, Jun 21, 2006 at 08:04:36PM +0200, Stefan Richter wrote:
>>
>>> What is wrong with the current two-line format?
>>
>>
>> Several things.  The way that it's printed means that simultaneous scans
>> lead to the output getting garbled.
> 
> 
> That's true, but it could be implemented as an atomic operation with
> multiple printks nonetheless. However you are right, layout should not
> be a reason to add locks. Make it one printk, but please keep it
> readable. The inquiry printout is one of the few that people actually
> care for.
> 
>> You're exaggerating.
> 
> 
> On purpose. :-)
> 
>> BTW, here's what a line would look like from sbp2 ...
>>
>> scsi 9:0:0:0: CD-ROM            MATSHITA  UJDA730 DVD/CDRW  1.00 Level: 0 
> 
> 
> Here is another SBP-2 device:
>    Vendor: ST340083  Model: 2A                Rev: 3.01
>    Type:   Direct-Access-RBC                  ANSI SCSI revision: 04
> 
> This may be misleading if "Vendor:" and "Model:" prefixes are stripped.
> 
>> btw, I've always found that "CD-ROM" a little confusing; considering
>> that SPC4 says "CD/DVD device", any objections to changing that string
>> to say "CD/DVD" instead of "CD-ROM"?
> 
> 
> Seems reasonable.

Matthew,
Here are short and long lists that I dug up from
sg3_utils and lsscsi. The long list should adhere
to the SPC-4 pdt names more closely:

static const char * scsi_pdt_strs[] = {
    /* 0 */ "disk",
    "tape",
    "printer",
    "processor",        /* often SAF-TE (seldom scanner) device */
    "write once optical disk",
    /* 5 */ "cd/dvd",
    "scanner",
    "optical memory device",
    "medium changer",
    "communications",
    /* 0xa */ "graphics [0xa]",
    "graphics [0xb]",
    "storage array controller",
    "enclosure services device",
    "simplified direct access device",
    "optical card reader/writer device",
    /* 0x10 */ "bridge controller commands",
    "object based storage",
    "automation/driver interface",
    "0x13", "0x14", "0x15", "0x16", "0x17", "0x18",
    "0x19", "0x1a", "0x1b", "0x1c", "0x1d",
    "well known logical unit",
    "no physical device on this lu",
};

static const char * scsi_short_device_types[] =
{
        "disk   ", "tape   ", "printer", "process", "worm   ", "cd/dvd ",
        "scanner", "optical", "mediumx", "comms  ", "(0xa)  ", "(0xb)  ",
        "storage", "enclosu", "sim dsk", "opti rd", "bridge ", "osd    ",
        "adi    ", "(0x13) ", "(0x14) ", "(0x15) ", "(0x16) ", "(0x17) ",
        "(0x18) ", "(0x19) ", "(0x1a) ", "(0x1b) ", "(0x1c) ", "(0x1e) ",
        "wlun   ", "no dev ",
};

There are no known unknowns ...

Doug Gilbert