On Thu, Feb 09, 2006 at 02:55:15PM -0500, Alan Stern wrote: > A fair number of SCSI BLIST bits have duplicate entries in the scsi_device > structure (in one instance the meaning is inverted): > > BLIST_BORKEN borken > BLIST_SINGLELUN single_lun > BLIST_USE_10_BYTE_MS use_10_for_ms > BLIST_MS_SKIP_PAGE_08 skip_ms_page_8 > BLIST_MS_SKIP_PAGE_3F skip_ms_page_3f > BLIST_MS_192_BYTES_FOR_3F use_192_bytes_for_3f > BLIST_RETRY_HWERROR retry_hwerror > BLIST_NOT_LOCKABLE lockable > BLIST_NOSTARTONADD no_start_on_add > > There's no good reason for this duplication. It's largely historical; at > the time the device flags were added there was no way to alter the bflags > value. Now there is, since sdev_bflags is stored in the scsi_device. > > Should we keep this duplication? Should we remove the device bits and use > the sdev_bflags bitmasks instead? I presume we don't want to remove the > BLIST entries because they are visible to userspace. (Although probably > some of them are not used anywhere at all.) I'd like to see the bit fields replaced by sdev_flags masks. Best with a macro or macros. I don't see why you would get rid of the BLIST_NNN fields even ignoring user space and devinfo, as you can use them as the mask values. Higher level macros would be easier to replace if we ever move the flags into the starget or such. I mean if we have: #define scsi_nostartonadd(sdev) (sdev->sdev_bflags & BLIST_NOSTARTONADD) Used as: if (scsi_nostartonadd(sdev)) ... It can easily be changed in the future to: #define scsi_nostartonadd(sdev) \ (sdev->sdev_target->starget_bflags & BLIST_NOSTARTONADD) > What about things like BLIST_REPORTLUN2 and BLIST_NOREPORTLUN? They don't > mean anything for scsi_devices, only for scsi_targets. Nevertheless they > are part of the same BLIST entries. Again, I don't see any way around > that without affecting userspace. A lot of the values are really per target, maybe all of them, plus we have those bit fields that are set by the host driver (or transport). And the devinfo code treats them as per vendor + product. IMO store them all in sdev_bflags for now. For a given target is it allowed per standard, or does hardware exist that returns a different vendor and product for different LU's? I don't see anything looking at the SPC 3 for INQUIRY. It doesn't make much sense to me, but then there are some crazy devices out there. -- Patrick Mansfield - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
