Nicholas A. Bellinger, on 08/31/2010 01:46 AM wrote:
Sorry, but you are completely wrong here. This has nothing to do with a
question of STGT kernel 'ABI compatibility' (because there is only one
mainline user!), but has everything to do with being able to expose TCM
kernel level SPC-4 emulation, and make this logic available to existing
userspace fabrics in tgt.git. Again, we are talking about userspace
STGT fabric module<-> TCM kernel backstore support for .37, which has
already been merged by into tgt.git, and being used by other STGT users
for SG_IO and BSG passthrough.
You are proving that I'm actually right ;). In the beginning of this
thread I offered a transition path from STGT to SCST and James rejected
it, because it didn't confirm a requirement that a new SCSI target
infrastructure must be STGT ABI compatible. But latter James left this
decision up to the STGT developers and now you are confirming that they
don't see any ABI compatibility issues, so my transition path fully
confirms all the requirements.
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".
The same is for the second half of the above. It's for scst_local in the
same degree as for TCM_Loop.
I'm not deciding anything, I'm only analyzing and seeing a contradiction:
1. James wants only one SCSI target infrastructure in the kernel.
2. If drivers/scsi/scsi_tgt_*.c left after the merge of the new SCSI
target infrastructure, it would mean that STGT left as well => 2 SCSI
target infrastructure in the kernel.
For me it doesn't matter. I just want clear rules, hence asking for
clarification.
Seriously, arguing over the use of people's language from weeks ago once
the decision has already been made to move forward is really of little
value at this point.
Does it look I'm arguing? Again, I'm analyzing and asking for
clarification in the contradictions I see. I don't like when such
important decisions are done behind closed doors and kept in a secret.
It is obvious to even an casual observer from watching the TCM/LIO patch
series that have been flying across the linux-scsi wire the last 24
months that the major features (including PR and ALUA, and new fabric
module drivers) have been developed individual feature bit by feature
bit using a distributed git workflow in a bisectable manner. Each
series was produced in such a manner that each patch could be reviewed
individually by those interested parties.
That's a nice, but quite meaningless LIO advertisement. SCST is using
the same bisectable, distributed and reviewable workflow.
Actually, that is incorrect. Your project uses a centralized
development model, which has it's obvious limitiations in terms of
speed, flexability, and community scale. But really, don't take my word
for it, you can hear it for yourself directly from the horse's mouth
here:
http://www.youtube.com/watch?v=4XpnKHJAok8
I also very strongly suggest you find a transcript of this talk so you
can really understand what Linus means here wrt to a distributed
development workflow.
Well, Nicholas, are you really understanding what you are writing? We in
our projects have fully the same distributed (or centralized, if you
like it) development model. Have you noticed how many developers SCST
project has? We have our responsibility areas (target drivers,
scstadmin, etc.) and commit in them. The way how we get updates for the
rest of the kernel doesn't matter. Git is better for such huge projects
as the kernel, but for our relatively small and centralized by nature
due to small size (sub)projects it doesn't matter and won't bring any value.
Actually, to have all in one place without the rest of the kernel is
more convenient, because grep over few MBs is a lot faster than over the
few hundreds of MBs of the full kernel sources.
If we had a
kernel.org git account, we would use it as well, but so far we are happy
with SF.net hosting. BTW, how was you able to get the git account
without a single patch merged in the kernel? You must have good
connections in the kernel community.
Please don't turn this into a kernel.org vs. SF.net thing.. There are
plenty of places that offer free git hosting (see github)
SF.net for a long time has been offering git hosting, but we don't see
reasons to move to it. SVN has all we need. We are not (yet) so big to
need git.
But, we can move to git at any moment as soon as it is needed, for
instance, because of SCST merged in the mainline kernel.
This is the big difference between our respective development processes.
This is the case not only for SCSI feature bits that TCM/LIO and SCST
share, but for features in TCM/LIO v4 that are unique and not available
in any other target implemention, anywhere. And yes, I am most
certainly talking about code beyond just the SCSI level fabric emulation
bits you are mentioning above.
Can you list us benefits for an average user of that work?
Well, amougst the biggest advantages is actually having a sane ConfigFS
interface that can represent the parent / child relationship between
data structures across multiple LKMs.
Does STGT represent it in an insane manner?
Not only does this give us a
proper representation of TCM and fabric data structures that can be
accesses directly by an advanced user in /sys/kernel/config/target/, it
also provides an ideal foundation to build 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.
But wrt to actual kernel code (because this is a kernel list), the
shortlog for the RFC posting below nicely sums up what TCM v4 is
bringing to the table:
http://lkml.org/lkml/2010/8/30/88
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.
Also what advantages and additional value it has over what SCST
*already* provides since 2007?
But all my attempts to explain my view are just blindly
ignored without any considerations, so I have no idea how more I can
explain it.
Then I suggest you learn a better way of communicating your ideas if you
really want to work with members of the LIO/STGT development
communities.
First, I suggest you start explaining your ideas with actual kernel code
that is 1) human readable and 2) presented in such a manner that makes
it accessable for others with skills possibly different (and greater)
than your own to review and give feedback.
I have sent patches twice, the second time few months ago. Weren't they
human readable and accessible for kernel developers who are experts in
dealing with sent by e-mail patches?
I think a proper kernel subsystem maintainer workflow has to do alot
more to do these days than just sending patches over email, than it did
say 10 years ago. Like it or not, git is the language of the mainline
kernel development process, and trying to imagine a *new* kernel
subsystem maintainer (besides say, someone like akpm) not using git is
quite a stretch of the imagination at this point.
So, do you believe that as soon as we migrate to git all the obstacles
for the SCST merge would be immediately removed?
Thanks,
Vlad
--
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
