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
next prev parent 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.