Again, I still have no idea what you are trying to conjour up. The
passthrough for STGT compatibility with TCM_Loop via SG_IO and BSG has
already been merged by Tomo-san into tgt.git. Futhermore, we are using
the same TCM_Loop high level multi-fabric WWPN emulation together with
new (and old) QEMU HBA emulation into KVM guest using SG_IO and BSG as
well.
The patches were good, but don't mislead people about that. For sake of
clearness, what you called "the passthrough for STGT compatibility with
TCM_Loop via SG_IO and BSG" has nothing with LIO/TCM_Loop. What merged
fixed problems STGT had in the pass-through implementation. It at the
same time fixed problems with SCST's scst_local, so similarly can be
called "the passthrough for STGT compatibility with scst_local via SG_IO
and BSG".
Uh, I don't think TCM_Loop and scst_local are exactly comparable at this
point. TCM_Loop supports high level multi-fabric WWPN emulation that
allows it to work transparently with inter-nexus SPC-4 PR operation.
Therefore, using TCM_Loop, STGT userspace fabrics now support both PR
and ALUA emulation from TCM_Loop LUNs. This is done at struct
config_group_ops->make_group() time to report $PROTO_IDENT and the
necessary WWPN info to TCM Core logic. TCM_Loop also uses the fabric
indepent configfs handlers for pretty much all of it's control plane
code.
I have no doubts in benefits to TCM. But I have asked about benefits
_for an average user_. STGT already can do what you listed above.
Again, from above how it benefits users:
1) a userspace library in intrepted languages and 2) create high level
applications using said userspace libraries that allow compatiblity to
be contained in the lib below.
2) create high level applications using said userspace libraries that
allow compatiblity to be contained in the lib.