goggin, edward wrote:
Mike, I don't think it is reasonably possible to anticipate all possible parsing requirements for the asc and ascq portions of SCSI sense information across all device models. I'm in favor of having a "small" framework in SCSI where a SCSI sense interpreter module (per vendor & model possibly) could be registered dynamically, by dm-emc.c for instance.
Yeah I agree, I mentioned this before in some other mails. I think a module versus some table that userspace could write to were discussed.
The BLKERR values were meant to be able to tell upper layer code whether a transport or device or driver error occured and whether the lower level thought it was retryable. But then I thought I could also wedge in the handling of the vendor specifcs by adding a vendor specific SCSI module that would map the their specific value to a BLKERR_* one. And as I said offlist it is not working perfectly becuase we are losing some information in the translations.
The extended error interpreter callout would be triggered indirectly by a call from __end_that_request_first to a extended error parser associated with the io request's queue whenever it sees a non-zero sense field of the io request. Perhaps the sense and sense_len fields in the request structure should be changed to not be SCSI specific.
So this just handles the sense type of error right? We still need something seperate for the transport and device etc errors correct?
Also, in order to allow for more variation and detail in the interpretation of device specific SCSI asc and ascq values, the results of the interpretation should not be required to be block layer generic, but instead are saved in something like a void *bi_extended_error field of the bio. __end_that_request_first would push the results of the extended_error interpretation to the bi_extended_error field of each bio in the request, similar to how Jens's code currently works. This extended error parsing approach should extend easily (without requiring a kernel revision for new BLKERR values) to new SCSI devices/models and their device specific asc and ascq values. This design could also be extended to support the interpretation of extended error information for non-SCSI block devices like DASD.
I am fine with such a thing. You basically described what we have been talking about for some time but sperated the BLKERR part from the vendor specific part (which solves the problem I was having in trying to use the BLKERR value for two things). I am not the decision maker though so.
- : 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
