On 07/31/2014 11:00 AM, Jerome Martin wrote:
> Regarding the code, Jerome, I'd really like to carry across the
> improvements in -fb, but think there were things that I removed
> (loadable .specs? backwards compat?) that prevented you from basing your
> new development on it. Can you talk a little about what you'd need in a
> converged version?
Well, the major points are obviously API incompatibilities, and as you
mentioned the removal of dynamic/generic module support stuff around the
specfiles. It was a design requirement for rtslib to be able to support
newer kernel modules without deploying a new rtslib version and/or
patching the current version. A third-party fabric module author would
just need to ship a specfile along with its module to get support.
From Datera's perspective, there were customers using rtslib (just via
targetcli? Or also directly? I don't know) but from my perspective when
branching -fb there were none besides targetcli-fb, which was also
getting branched. Thus there was no reason to constrain code
improvements based on backwards compatibility (except across kernel
versions). This has enabled significant progress.
About specfiles - this doesn't really have value for anyone not using
out-of-tree kernel modules, so as new features like WWN normalization
required tighter integration with fabrics, they first became python
modules instead of sed snippets, and then were consolidated into
fabric.py. So, while I am against out-of-tree kernel modules on
principle, it would be easy to add support back for separate fabric
definition files in rtslib-fb, if it's that important to you.
> Regarding development cooperation, I'm for it. But licensing wasn't the
> only issue that resulted in the -fb branch, so we'd need to work through
> those issues (release engineering, public discussion of future plans,
> ensuring timely bugfixes) too for it to be successful.
Well, all those three points could improve dramatically if we joined
forces
Maybe, maybe not. Let me lay it all out for you from my perspective:
PROS (of reunifying)
- Improved feature set
- Unified and larger user base helps LIO win against other target
implementations, and leads to more developers and users
- Less user confusion
- Share the maintenance/release work
- More code review -> better code quality
CONS
- Nonzero chance of disagreements about direction and features, possibly
leading to another fork, which would look REALLY bad
- Amt. of work to unify codebases
- Extra features that only benefit commercial users
- Code review delays timely bugfixes
Just wanted to put it out there. I think it would be good, but there are
actual and potential downsides that we shouldn't ignore. What we have
now (separate public trees) might not be the worst - we're trading
bugfixes now, which is nice.. maybe we could collaborate on a feature
that would improve both, as a smaller step?
- The configuration API and reasoning behind it, with major implications
for the future development, again see
http://thread.gmane.org/gmane.linux.scsi.target.devel/5838
- The generic fabric support based on specfiles.
Andy, if you agree to it, I can dedicate some time this summer so that
we can work on this and come up with a plan. What do you think?
Sure if you want to start looking at stuff that'd be great, but we
should keep hashing out the other stuff too. BTW, keep in mind that
since targetcli-fb shipped in RHEL 7, I also have compatibility issues
and a stable branch to worry about, just like you. :-/
Regards -- Andy
--
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
