On 03/30/2010 07:01 PM, Douglas Gilbert wrote: > The folk at t10.org slipped this innocuous looking > addition into sam5r04 section 5.3.1 on status codes. > > "Sense data may be delivered in the buffer defined by > the Sense Data argument of the Execute Command > procedure call (see 5.1) for any status code." > > Previously sense data was only valid for status > CHECK_CONDITION [0x2] (and the obsolete > COMMAND_TERMINATED [0x22]). The quoted section in > the previous paragraph means that sense data could > arrive with any status code. > > And now with draft sbc3r22 there is an example: > status=GOOD, sense_key=COMPLETED (recently added) > additional_sense_qualifier="INSPECT REFERRALS > SENSE DESCRIPTORS". Referrals are new and explained > in sbc3r22. IMO only a very small audience would > be interested in them. However it does indicate > a new trend. > > > So the question for the Linux scsi subsystem is > does it (or can it without many changes) convey > "non CHECK_CONDITION" sense data back up from > an initiator (LLD) to code that might care? > scsi_cmnd->sense_buffer has an hard coded max_size and no associated current_size member. the scsi-ml, given a CHECK_CONDITION, will analyse the ->sense_buffer and determine it's size, then will copy the content and set the size into request's sense members. All this you already know. Now what do you want to happen? A. Only LLD knows when sense is available through host specific flags. In that case: I propose a new scsi_set_sense() that will just set the proper request members. It should be called only if != CHECK_CONDITION, since in that case it will just be over-written by the scsi-ml again. (Or not that can be changed as well). [This is a simple change, but needs LLD specific code every time] B. The protocol defines when a sense is available, by status + cmnd combination, the sense is set by the target, the LLD has no special knowledge if sense is present or not. In this case scsi-ml can just inspect for these conditions and copy sense up the stack as before. Next step is for some ULD, to actually inspect these fields. > Doug Gilbert > It does not look too complicated either way. Boaz -- 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
