Re: [dm-devel] 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.
>
> 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.
>
> 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.

I have been working on this but a issue I was wondering about is what to 
do when someone other than dm-multipath wants to know about this special 
error value. For example when we first discover devices if it is passive 
path, we have to go through the pain of the regular setup and any 
retires that arise from it. If people are not going to complain about 
this anymore then you can ignore this mail :) But the problem (or issue 
people gripe about) is that if there is a magic ASC/ASCQ value for 
vendor XYZ that indicates we are sending requests to a passive path then 
who decodes the bi_extended_error value when dm-mutliapth is not used? 
Will we have to have a vendor specific bi_extended_error decoder for 
dm-mpath, filesystems and buffer head code, and what about SCSI?
-
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