Re: [RFC PATCH 4/4] convert scsi to blkerr error values

goggin, edward wrote:
> > -----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
> cosense. In Lars's comments it stated we may need to send another request 
> nference calls.  I wasn't sure if you were still advocating for this
> approach though :))

To actually implement the vendor specifics, I think I was just being 
lazy and waiting to hear about what people need when they decode the 
sense. In Lars's comments it stated we may need to send another request 
to determine if the paths need to be failed. I think SUN  may have 
wanted the same thing. Any ideas? Did you guys need to do this in your 
multipath solution?
-
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