From: James Bottomley <jejb@linux.vnet.ibm.com>
To: Hannes Reinecke <hare@suse.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Martin Wilck <mwilck@suse.com>
Cc: linux-scsi@vger.kernel.org, saito.kazuya@jp.fujitsu.com
Subject: Re: [PATCH] scsi: handle ABORTED_COMMAND on Fujitsu ETERNUS
Date: Thu, 18 Jan 2018 06:24:15 -0800 [thread overview]
Message-ID: <1516285455.3014.2.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <00bbbaed-215a-4af9-1576-1c25008d0e23@suse.de>
On Thu, 2018-01-18 at 11:17 +0100, Hannes Reinecke wrote:
> On 01/18/2018 03:43 AM, Martin K. Petersen wrote:
> >
> >
> > Martin,
> >
> > >
> > > You'd like to spend a precious BLIST bit for this single device
> > > which uses vendor-specific ASC/Q?
> >
> > I really don't want string comparisons in the regular code paths.
> > Also not a fan of vendor-specific ASCs. But if you must use them,
> > please add a flag and trigger on that.
> >
> > Since this is a bit of an unusual check condition combo, we could
> > entertain whether we should simply always ADD_TO_MLQUEUE on
> > 0xb/0xc1/0x1. I wonder what would break?
> >
> That's the usual problem I have with vendor-specific sense codes.
> In general the risk is quite low of different vendors actually using
> the same code; I guess we can get away with just adding a debug
> message here and enable it without any vendor check.
> Then we can reconsider the whole thing once we notice several vendors
> using the same sense codes.
Murphy's law says that if we rely on Vendors to chose non-overlapping
numbers we'll end up with a clash fairly quickly ...
Can't we find a way of doing this in the device_handler? That way we
can use vendor specific codes only when we know who the vendor is?
James
next prev parent reply other threads:[~2018-01-18 14:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 20:18 [PATCH] scsi: handle ABORTED_COMMAND on Fujitsu ETERNUS Martin Wilck
2018-01-17 6:15 ` Martin K. Petersen
2018-01-17 7:32 ` Martin Wilck
2018-01-18 2:43 ` Martin K. Petersen
2018-01-18 10:17 ` Hannes Reinecke
2018-01-18 14:24 ` James Bottomley [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-01-17 16:13 Xose Vazquez Perez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1516285455.3014.2.camel@linux.vnet.ibm.com \
--to=jejb@linux.vnet.ibm.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mwilck@suse.com \
--cc=saito.kazuya@jp.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).