Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@ozlabs.org>
To: Hannes Reinecke <hare@suse.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi: Make scsi_vpd_lun_id() able to use T10 vendor ID based designators
Date: Thu, 5 May 2016 13:50:10 +1000	[thread overview]
Message-ID: <20160505035010.GA4635@oak.ozlabs.ibm.com> (raw)
In-Reply-To: <5729C920.1040206@suse.de>

On Wed, May 04, 2016 at 12:04:16PM +0200, Hannes Reinecke wrote:
> On 05/04/2016 08:58 AM, Paul Mackerras wrote:
> > This adds code to scsi_vpd_lun_id() to enable it to use T10 vendor ID
> > based designators.  This is needed to allow alua to work on disks that
> > don't have any designators of type 2, 3 or 8.  Commit 0047220c6c36
> > ("scsi_dh_alua: use unique device id", 2016-02-19) added a requirement
> > that alua can only be used on disks for which scsi_vpd_lun_id() can
> > produce an identifying string.
> > 
> > Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
> > ---
> >  drivers/scsi/scsi_lib.c |   14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index 8106515..f4f69cc 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -3214,6 +3214,20 @@ int scsi_vpd_lun_id(struct scsi_device *sdev, char *id, size_t id_len)
> >  			goto next_desig;
> >  
> >  		switch (d[1] & 0xf) {
> > +		case 0x1:
> > +			/* T10 vendor ID */
> > +			if (cur_id_size > d[3])
> > +				break;
> > +			/* Prefer EUI-64 or NAA IEEE Registered Extended */
> > +			if ((cur_id_type == 0x2 || cur_id_type == 0x3) &&
> > +			    cur_id_size == d[3])
> > +				break;
> > +			cur_id_size = d[3];
> > +			cur_id_str = d + 4;
> > +			cur_id_type = d[1] & 0xf;
> > +			id_size = snprintf(id, id_len, "%*phN", cur_id_size,
> > +					   cur_id_str);
> > +			break;
> >  		case 0x2:
> >  			/* EUI-64 */
> >  			if (cur_id_size > d[3])
> > 
> Nearly.
> The thing is, a T-10 vendor specific ID is _supposed_ to be an ASCII
> string. So I'd rather have it decoded as such.

Do we need to defend against non-printing characters in the string?

> And we're missing decoding for 'vendor-specific' ID, too.

There's no guarantee that this would be ASCII, right?  So would you
print it in hex?

Also, is there a preference between these types?  For example, is an
8-byte EUI-64 preferable to a vendor-specific ID of any length?

Cheers,
Paul.

  reply	other threads:[~2016-05-05  3:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-04  6:58 [PATCH] scsi: Make scsi_vpd_lun_id() able to use T10 vendor ID based designators Paul Mackerras
2016-05-04 10:04 ` Hannes Reinecke
2016-05-05  3:50   ` Paul Mackerras [this message]
2016-05-05  8:01     ` Hannes Reinecke
2016-05-05 12:41       ` Paul Mackerras
2016-05-06  9:46         ` Hannes Reinecke

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=20160505035010.GA4635@oak.ozlabs.ibm.com \
    --to=paulus@ozlabs.org \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    /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