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