On Mon, 8 Jan 2007, Douglas Gilbert wrote: > Alan Stern wrote: > > Both scsi_device and scsi_target include a scsi_level field, and the > > SCSI core makes a half-hearted effort to keep the values equal. > > Ultimately this effort may be doomed, since as far as I know there is > > no reason why all LUNs in a target must report the same "ANSI-approved > > version" number. But for the most part it should work okay. > > > > This patch (as834) changes the SCSI core so that after the first LUN > > has been probed and the target's scsi_level is known, further LUNs > > default to the target's scsi_level and not to SCSI_2. > > Alan, > Umm, scsi_level is a mangled value derived from the > "version" field in an INQUIRY standard response. As > such it is per logical unit ***. There is nothing to stop > a single target (especially if it is a bridge that > maps targets at the remote end to luns) having a wide > variety of lus with different "version" values (and > different peripheral device types). Yes, I know. In fact I said as much in the patch description. > IMO scsi_level should only be per lu which means it > should only exist in the scsi_device structure. That would make sense. But the current codebase has it in the scsi_target structure as well. I don't know why. The only place it seems to be used is in scsi_report_lun_scan(). > If the scsi mid level was really advanced it could > track the "version" value in the INQUIRY response to > "well known" logical units (see spc4r08.pdf section 8) > because these really are per target. I don't expect > that to happen any time soon (and there wouldn't be > much benefit). That would be the logical thing to do when scsi_level is removed from scsi_target. > So the existing code seems broken but I'm not sure > your patch advances things. It does, because it prevents the core from sending an INQUIRY to higher LUs with the LUN bits in CDB[1] set if LU-0 has already reported scsi_level==0. Alan Stern - To unsubscribe from this list: 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
