On Mon, 2015-05-18 at 10:51 -0700, Christoph Hellwig wrote: > On Thu, May 14, 2015 at 10:21:11AM +0200, Tomasz Charo??ski wrote: > > First of your representation concept seems to be great. Each NPIV has an > > option to set individual acls and luns, so it will be clear. In my > > opinion, also there is no sense in treating qla2xxx_npiv as a separate > > fabric, because it's served from the same driver (qla2xxx). NPIVs have > > to have their physical parent; the first representation give us an > > information about parent in more transparent way. > > FYI, this reminds me of the patch below I did a while ago that > splits the configfs from the fabric ops to make this more clear. I've > rebased it to the latest target/for-next that works for me (without > the RCU changes which will cause some very minor clashes). > > After that the next step might be to redo the configfs ops and > move them into common code for both the FC and FC+NPIV cases. > I'm not crazy about splitting up target_core_fabric_ops back into separate structures for fabric vs. configfs callbacks again. What's in place for v4.2 with target_register_template() is nice and simple, and breaking this out further for just the FC NPIV case doesn't really justify the extra complexity. --nab -- 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
