scsi_common: Modify SMR device type to reflect SCSI specification

scsi_common: Modify SMR device type to reflect SCSI specification

[Petros Koutoupis]

This change is purely cosmetic but we should adjust device type 0x14 to
reflect the definition given in the SCSI specification standard (SPC-5).

Implying Direct-Access assumes that the device supports the traditional
Direct-Access command set when Host Managed Zoned Block Devices support
a subset of that command set with a few zone specific additions. Please
refer to the ZBC for details.

Signed-off-by: Petros Koutoupis <petros@petroskoutoupis.com>

--- linux/drivers/scsi/scsi_common.c.orig	2016-05-12 12:23:04.450000000 -0500
+++ linux/drivers/scsi/scsi_common.c	2016-05-12 12:29:08.382000000 -0500
@@ -14,27 +14,27 @@
  * encouraged once assigned by ANSI/INCITS T10
  */
 static const char *const scsi_device_types[] = {
-	"Direct-Access    ",
-	"Sequential-Access",
-	"Printer          ",
-	"Processor        ",
-	"WORM             ",
-	"CD-ROM           ",
-	"Scanner          ",
-	"Optical Device   ",
-	"Medium Changer   ",
-	"Communications   ",
-	"ASC IT8          ",
-	"ASC IT8          ",
-	"RAID             ",
-	"Enclosure        ",
-	"Direct-Access-RBC",
-	"Optical card     ",
-	"Bridge controller",
-	"Object storage   ",
-	"Automation/Drive ",
-	"Security Manager ",
-	"Direct-Access-ZBC",
+	"Direct-Access     ",
+	"Sequential-Access ",
+	"Printer           ",
+	"Processor         ",
+	"WORM              ",
+	"CD-ROM            ",
+	"Scanner           ",
+	"Optical Device    ",
+	"Medium Changer    ",
+	"Communications    ",
+	"ASC IT8           ",
+	"ASC IT8           ",
+	"RAID              ",
+	"Enclosure         ",
+	"Direct-Access-RBC ",
+	"Optical card      ",
+	"Bridge controller ",
+	"Object storage    ",
+	"Automation/Drive  ",
+	"Security Manager  ",
+	"Host Managed Zoned",
 };
 
 /**

Re: scsi_common: Modify SMR device type to reflect SCSI specification

[James Bottomley]

On Sat, 2016-05-21 at 20:58 -0500, Petros Koutoupis wrote:
> This change is purely cosmetic but we should adjust device type 0x14 
> to reflect the definition given in the SCSI specification standard 
> (SPC -5).
> 
> Implying Direct-Access assumes that the device supports the 
> traditional Direct-Access command set when Host Managed Zoned Block 
> Devices support a subset of that command set with a few zone specific 
> additions. Please refer to the ZBC for details.

This string is output via an sdev_printk.  Technically, that makes it a
an ABI for stuff that does log parsing.  It's only a weak ABI because
logs are somewhat changeable so it's not that we can't do this, but I'd
like a good reason before doing it.

Can you explain why you want do do this? ... your change log is very
vague.  I think it's because you think we should more closely reflect
the language in table 148 (peripheral device type field) but that's not
very convincing because none of the rest of our definitions exactly
reflect that language either.  Plus the current definition reflects how
RBC devices are presented, so it seems logical.

James

Re: scsi_common: Modify SMR device type to reflect SCSI specification

[Petros Koutoupis]

On Sun, 2016-05-22 at 10:20 -0700, James Bottomley wrote:
> On Sat, 2016-05-21 at 20:58 -0500, Petros Koutoupis wrote:
> > This change is purely cosmetic but we should adjust device type 0x14 
> > to reflect the definition given in the SCSI specification standard 
> > (SPC -5).
> > 
> > Implying Direct-Access assumes that the device supports the 
> > traditional Direct-Access command set when Host Managed Zoned Block 
> > Devices support a subset of that command set with a few zone specific 
> > additions. Please refer to the ZBC for details.
> 
> This string is output via an sdev_printk.  Technically, that makes it a
> an ABI for stuff that does log parsing.  It's only a weak ABI because
> logs are somewhat changeable so it's not that we can't do this, but I'd
> like a good reason before doing it.
> 
> Can you explain why you want do do this? ... your change log is very
> vague.  I think it's because you think we should more closely reflect
> the language in table 148 (peripheral device type field) but that's not
> very convincing because none of the rest of our definitions exactly
> reflect that language either.  Plus the current definition reflects how
> RBC devices are presented, so it seems logical.
> 
> James
> 

James,

I get it. It was more of a suggestion anyway. And you are correct, my
reason was t be closer to the language of the peripheral device type field
in the inquiry string.

--
Petros