Hi Christoph, Andy et al.,
I am splitting this reply out the the original thread, as I feel this
deserves a topic on its own.
On 07/29/2014 06:47 PM, Andy Grover wrote:> On 07/29/2014 06:24 AM,
Christoph Hellwig wrote:
>> Btw, what's the status of the targetcli trees? I though with the
>> licensing updates we'd be able to get a unified version again.
First of all thanks Christoph for bringing the reunification topic on
the table, and thanks Andy for confirming below your are all for it :-)
This would be really beneficial for all users if we can make that happen
as soon as possible.
> The status of the trees is.. they've diverged. targetcli-fb in many
> smaller ways, and Datera targetcli in the addition of a new config API.
> See below.
Yes, diverged is the word. I even think the -fb API diverged so much as
to have compatibility problems with the main branch API :-(
> Both are Apache-licensed now, so licensing is fixed. The remaining
> issues I see are reunifying the code and cooperating on development.
<nod>
> 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.
However, this is a good opportunity to discuss specfiles, as an option
might be to absorb that functionality in the new configuration code.
> 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, and I obviously agree that these are important. I hoped I made
it clear that I wanted to stress those, as a goal, when I posted the 3.x
series announcement (link is the same gmane URL seen above and below :-) ).
>> Can anyone in the loop explain what the current set of major differences
>> are?
>
> Maybe Jerome wants to add more, but for Datera targetcli, it's the new
> config API:
>
> http://thread.gmane.org/gmane.linux.scsi.target.devel/5838
>
> For targetcli-fb:
>
> * targetcli commands can be invoked from cmdline and return an error code
> * python 3 support
> * lio-utils is gone, config saved in .json format
> * Easier storage-ACL setup
> * WWN format standardized
> * Only show HW fabrics that are present
> * 10 previous configs saved
> * initiator ACL grouping
> * More info in summaries
> * iSER support
> * Caching for better scalability
> * added a manpage
> * rtslib: Remove .specfiles in favor of Python (fabric.py)
Yes, not much to add really. Of course some points in your list have
already been ported to the main tree, some points evolved independently
too, be it for iSER support, manpage or native configuration. I do not
really have the precise diff out of the top of my head, but the major
divergece points in my opinion are those already mentioned above, that
I'll repeat here for clarity:
- API incompatibilities, I am not using the -fb a lot, but I noticed
public API method signature changes while looking at the -fb commits
history.
- 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?
Best Regards,
--
Jerome Martin
--
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
