On 09/30/2015 07:49 PM, Andy Grover wrote: > On 09/30/2015 10:32 AM, Hannes Reinecke wrote: > >>> If so, I wonder if a compile-time config option to change it from >>> the >>> default might be sufficient. >>> >> Sure we could make this a compile-time option, but that would require >> everyone building a storage appliance to recompile the module/kernel. >> Which is not what we as an OS vendor would want. >> (And I guess RH will have the same opinion wrt rebuilding kernel >> modules >> ...) > > Ah, true. > > And, having it in configfs means userspace can read it easily. > > Do we need to worry about what happens if vendor id changes at > runtime, for already-exported luns? Or can we just assume nobody > would try that? > > Would there be any benefit in making this a per-target, per-tpg, or > per-lun attribute? (I can't think of any but wanted to raise the > question.) > The vendor ID is describing the target implementation. And it'll be rather hard to have different implementations for LUNs being exported from the same host ... We need to be careful to not clutter the vendor ID namespace. Most OS uses it to distinguish target implementation details (think of multipathing) and it will become an absolute mess if we have different vendor ID per LUN, all using the same implementations. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
