On Sun, 18 Jul 2004, Matthew Orgass wrote:

> On 2004-07-18 fredb@immanent.net wrote:
>
>> It's more than just window dressing. With "cdrdao", for instance, you
>> may not make entries in the driver settings table with missing fields.
>>
>> One possibility that suggests itself is to modify scsipi_strvis() to
>> return "UNKNOWN" rather than an empty string in cases like this. Any
>> better ideas?
>
>  Does returning no vendor id violate the spec?

Looking on this some more, the "vendor id" is evidently a fantasy 
induced by the ata-to-scsi layer. The block returned from ATA IDENTIFY 
has only a "model number" field, and a "serial number" field.

I don't have a printed copy of the ATA spec, but this language, from a 
recent ATA-7 draft, appears to be unchanged from a pre-ATA-6 draft:

  6.17.21 Words (46:27): Model number

  This field contains the model number of the device. The contents of this
  field is an ASCII character string of forty bytes. The device shall pad
  the character string with spaces (20h), if necessary, to ensure that
  the string is the proper length. The combination of Serial number (words
  (19:10)) and Model number (words (46:27)) shall be unique for a given
  manufacturer (See 3.2.9).

So, while there's nothing in there to suggest that either is optional, 
as a matter of fact, many manufactures apparently leave the serial 
number blank, putting the "vendor" and "model number" into the model 
number field, nor is it uncommon to leave the model number field 
blank, and only put the "model number" into the "serial number" field.

The following hack demonstrates the true situation, by inserting 
"UNKNOWN" for missing model number or serial number data:

Index: sys/dev/scsipi/scsipiconf.c
===================================================================
RCS file: /cvsroot/src/sys/dev/scsipi/scsipiconf.c,v
retrieving revision 1.20
diff -u -r1.20 scsipiconf.c
--- sys/dev/scsipi/scsipiconf.c	18 Jan 2003 12:05:39 -0000	1.20
+++ sys/dev/scsipi/scsipiconf.c	18 Jul 2004 18:08:05 -0000
@@ -262,6 +262,10 @@
  	while (slen > 0 && STRVIS_ISWHITE(src[slen - 1]))
  		--slen;

+	if (slen == 0) {
+		strncpy(dst, "UNKNOWN", 7);
+		dst += 7;
+	}
  	while (slen > 0) {
  		if (*src < 0x20 || *src >= 0x80) {
  			/* non-printable characters */

Unfortunately, that only affects the boot message (window dressing), 
and not the SCSI ioctl. There's something interesting going on with 
the ioctl. Here's a CD-ROM drive which has apparently the same problem:

  # grep ^cd0 /var/run/dmesg.boot
  cd0 at atapibus0 drive 0: <LTN486S, , YUS3> cdrom removable
  cd0: 32-bit data port
  cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
  cd0(rccide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33) (using DMA data transfers)

and yet...

  # scsictl cd0 identify
  # /dev/rcd0d: scsibus0 target 0 lun 0 <LITEON, CD-ROM LTN486S, YUS3>

So where is that "vendor id" coming from? (That's a CD-ROM on current, 
and the device I'm having the problem with is a DVD+RW, on 2.0_BETA.)

>  If not, cdrdao should be
> fixed (do the replacement in cdrdao before the table lookup).  I don't
> like the idea of mucking with what is supposed to be device information
> unless necessary (other apps may be expecting the missing vendor).  If it
> is against the spec, then I think the text "NULL" would give a better hint
> that the device didn't really return this text.

Well, the online draft for MMC-4 similarly doesn't emphatically say 
that you have to return a vendor id, but I think it's unlikely that 
the SCSI layer is supposed to be returning blanks for that, and the 
fields are blank-filled, not null-terminated, so I think "UNKNOWN" 
explains the situation better. However, it would be far better to 
present the real vendor id, if possible.

For what it's worth, a google search on VOM-12E48X shows that linux 
apparently has the same issue of no vendor id for that drive, so that 
case should probably be worked around in the application anyway.


Frederick