> -----Original Message----- > From: Mike Christie [mailto:michaelc@xxxxxxxxxxx] > Sent: Friday, September 16, 2005 4:26 PM > To: goggin, edward > Cc: axboe@xxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; dm-devel@xxxxxxxxxx > Subject: Re: [RFC PATCH 4/4] convert scsi to blkerr error values > > 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. Yes, I first heard about this idea from you on one of the multipathing conference calls. I wasn't sure if you were still advocating for this approach though :)) > > 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? Yeah, I forgot about those. > > > > > 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
