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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.