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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
