All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Boot <bootc@bootc.net>
To: Martin Svec <martin.svec@zoner.cz>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	target-devel@vger.kernel.org,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: NAA breakage
Date: Sun, 11 Sep 2011 15:00:13 +0100	[thread overview]
Message-ID: <4E6CBEED.1090507@bootc.net> (raw)
In-Reply-To: <4E6CA0E6.8080300@zoner.cz>

On 11/09/2011 12:52, Martin Svec wrote:
> thanks a lot for your comments. Clearly there was a misunderstanding 
> of who is the vendor that defines what is "vendor-specific" in case of 
> LIO. Of course, it is easy for me to fix my userspace code to generate 
> serial numbers without these issues. But I suggest to enforce 
> vpd_unit_serial restrictions in configfs code because rtslib/lio-utils 
> is just a referential userspace implementation, not a kernel ABI.

I feel it's time to add my 2 cents to this discussion. A vendor-specific 
identifier in my mind could very well be what Martin uses it for, in my 
opinion - at least according to SPC-3. If the LIO stack cannot handle 
such use of identifiers the configfs code should refuse to accept such 
an identifier. If for example the LIO code only creates a valid NAA/WWN 
from a hex string of a certain length, it should only accept a hex 
string of that length. It should not be a requirement to exactly follow 
what rtslib does in every case.

Of course the way I see it the vendor specific identifier doesn't 
necessarily have anything to do with the NAA/WWN, so it would be nice if 
one could set both a WWN as a hex string of the correct length and 
format, and a vendor-specific string in a mostly freeform manner as long 
as it abides by SPC-3. The WWN shouldn't necessarily be generated from 
the vendor identifier.

Chris


  reply	other threads:[~2011-09-11 14:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4E494F9F.4000909@zoner.cz>
     [not found] ` <1313522082.2853.10.camel@haakon2.linux-iscsi.org>
     [not found]   ` <4E4BAB1D.6070104@zoner.cz>
     [not found]     ` <1313618333.9928.61.camel@haakon2.linux-iscsi.org>
     [not found]       ` <4E528F05.9090208@zoner.cz>
     [not found]         ` <4E6A0618.3040102@zoner.cz>
2011-09-09 21:38           ` NAA breakage Nicholas A. Bellinger
2011-09-10 15:00             ` Martin Svec
2011-09-10 20:37               ` Nicholas A. Bellinger
2011-09-11 11:52                 ` Martin Svec
2011-09-11 14:00                   ` Chris Boot [this message]
2011-09-12  7:35                     ` Nicholas A. Bellinger

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=4E6CBEED.1090507@bootc.net \
    --to=bootc@bootc.net \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.svec@zoner.cz \
    --cc=nab@linux-iscsi.org \
    --cc=target-devel@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 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.