LIO/SCST Merger

Last year, during the 2015 LSF/MM summit, it has been decided that the LIO/SCST merger project should proceed by sending the functionality upstream that is present in SCST but not yet in LIO. This will help to reduce the workload of target driver maintainers that maintain a version of their target driver for both LIO and SCST (QLogic FC and FCoE target drivers, Emulex FC and FCoE target

drivers, RDMA iSER target driver, RDMA SRP target driver, ...). My proposal is to organize a session during which the following is discussed:
* Which patches are already upstream in the context of the LIO/SCST merger project.
* About which patches there is agreement but that are not yet upstream.
* To discuss how to proceed from here and what to address first.

Quoted 6 lines · Bart Van Assche

Last year, during the 2015 LSF/MM summit, it has been decided that the LIO/SCST merger project should proceed by sending the functionality upstream that is present in SCST but not yet in LIO. This will help to reduce the workload of target driver maintainers that maintain a version of their target driver for both LIO and SCST (QLogic FC and FCoE target drivers, Emulex FC and FCoE target

Quoted 8 lines

drivers, RDMA iSER target driver, RDMA SRP target driver, ...). My proposal is to organize a session during which the following is discussed:
* Which patches are already upstream in the context of the LIO/SCST merger project.
* About which patches there is agreement but that are not yet upstream.
* To discuss how to proceed from here and what to address first.

Can you begin this in email ... I don't think any of us are clear if there's still an issue here ... or that we'd say more than send the patches upstream, like we did last year. Just reporting on patch status isn't that useful ... if there were design disputes or issues to discuss that caused the patches not to be accepted, that would be more useful.

Quoted 22 lines · James Bottomley

Quoted 12 lines · Bart Van Assche

Last year, during the 2015 LSF/MM summit, it has been decided that
the LIO/SCST merger project should proceed by sending the functionality upstream that is present in SCST but not yet in LIO.
This will help to reduce the workload of target driver maintainers
that maintain a version of their target driver for both LIO and SCST
(QLogic FC and FCoE target drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver, RDMA SRP target driver, ...). My

Quoted 8 lines

proposal is to organize a session during which the following is discussed:
* Which patches are already upstream in the context of the LIO/SCST
merger project.
* About which patches there is agreement but that are not yet upstream.
* To discuss how to proceed from here and what to address first.

Quoted 9 lines

Can you begin this in email ... I don't think any of us are clear if
there's still an issue here ... or that we'd say more than send the patches upstream, like we did last year. Just reporting on patch status isn't that useful ... if there were design disputes or issues to
discuss that caused the patches not to be accepted, that would be more
useful.

Hello James,

Several patch series have been posted by different authors. Some of these patch series have already been reworked several times for different kernel versions. I think a meeting in person would make it easier to discuss which patch series to take upstream first and thereby avoid to have to keep reworking these patch series against an evolving target API. These patch series are:

* Christoph Hellwig, [RFC] simplify session shutdown, January 14
(http://thread.gmane.org/gmane.linux.scsi.target.devel/11135).
* Nicholas Bellinger, [PATCH 0/2] target: Fix LUN_RESET active I/O + TMR
handling, January 12, 2016
(http://thread.gmane.org/gmane.linux.scsi.target.devel/11097).
* Bart Van Assche, [PATCH 00/21] SCSI target patches for kernel v4.5,
January 5 (
http://thread.gmane.org/gmane.linux.scsi.target.devel/10905)

Last year, during the 2015 LSF/MM summit, it has been decided that the LIO/SCST merger project should proceed by sending the functionality upstream that is present in SCST but not yet in LIO. This will help to reduce the workload of target driver maintainers that maintain a version

of their target driver for both LIO and SCST (QLogic FC and FCoE target drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver, RDMA SRP target driver, ...). My proposal is to organize a session during which the following is discussed:
* Which patches are already upstream in the context of the LIO/SCST merger project.
* About which patches there is agreement but that are not yet upstream.
* To discuss how to proceed from here and what to address first.

I'm going to downvote this topic just like last year with my PC hat on as I think it's a) not relevant or usefully discussable at LSF and b) framed the wrong way.

Quoted 3 lines

I'm going to downvote this topic just like last year with my PC hat on as I think it's a) not relevant or usefully discussable at LSF and b) framed the wrong way.

I'm not sure LSF is the right platform, but I gotta say that this thread indicates that there's bad blood going around here and it needs to sorted out.

[ ... ]

Quoted 2 lines · Nicholas A. Bellinger

[ ... ]

Hi Nic,

Since in the most recent years all my communication to you was neutral and professional in tone it is not clear to me why you wrote such a misleading and unfair e-mail. Anyway, I would like to point out that the following information is missing from your e-mail:
- That last year the storage HBA vendors and Linux distributor representatives who attended my session about this topic where unanimously enthusiastic about my proposal. You were the only attendee who was not (yet?) enthusiast.
- That I am working on sending the ib_srpt patches upstream you referred to in your e-mail and that a first version of that patch series has already been posted on the linux-rdma mailing list.
- Although five years ago some SCST users switched to LIO, recently several LIO users switched back to SCST because the latter is still more stable and easier to configure than LIO. In other words, it is in your own interest to help the LIO patches upstream that I posted recently.
- One of the reasons that the LIO core patches I'm working on are not yet upstream is because of how long it takes before you as a maintainer provide feedback. The first version of my patch to make ABORT and LUN RESET handling synchronous was posted on October 12, 2015. It took until November 15, 2015 before I received the first feedback from you for that patch.

Bart.

--
To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines

Last year, during the 2015 LSF/MM summit, it has been decided that the LIO/SCST merger project should proceed by sending the functionality upstream that is present in SCST but not yet in LIO. This will help to reduce the workload of target driver maintainers that maintain a version

Quoted 8 lines

of their target driver for both LIO and SCST (QLogic FC and FCoE target drivers, Emulex FC and FCoE target drivers, RDMA iSER target driver, RDMA SRP target driver, ...). My proposal is to organize a session during which the following is discussed:
* Which patches are already upstream in the context of the LIO/SCST merger project.
* About which patches there is agreement but that are not yet upstream.
* To discuss how to proceed from here and what to address first.

No, just no. If you've not been able to articulate the specifics of what you're talking about to the list by now, it's never going to happen.

You'll recall last year how things unfolded at LSF. You started comparing data structure TMR member names of no consequence to a larger LSF audience, and quickly tried to pivot into a discussion about adding hooks to LIO fabric drivers for your own out-of-tree nastiness.

I really fail to see how that helps LIO or upstream. To repeat. I'll not allow SCST's out-of-tree legacy requirements to limit LIO's future in upstream, and if you or your employer is still trying to get enterprise distros to listen to that nonsense behind the scenes, then please stop wasting everybody's time.

Bart, I really want to believe you and your employer have good intentions for LIO. However, being one of it's largest detractors in the past means that you have to really put your best foot forward on your interaction with the LIO community.

However, your inability to ask questions before acting, refusing to answer to all feedback on reviews for changes of substance, and not following the expected patch review progress without repeatably leading yourself and others down the wrong path really makes me start to question your intentions, or at least your abilities as a kernel contributor.

Also, you've not managed to merge any of the outstanding ib_srpt fixes from the last year, which brings us to a grad total of 6 small patches since the original merge of ib_srpt in Oct 2011.

# git log --author=Bart --oneline -- drivers/infiniband/ulp/srpt/
19f5729 IB/srpt: Fix the RDMA completion handlers
ba92999 target: Minimize SCSI header #include directives
2fe6e72 ib_srpt: Remove set-but-not-used variables
649ee05 target: Move task tag into struct se_cmd + support 64-bit tags
afc1660 target: Remove first argument of target_{get,put}_sess_cmd()
ab477c1 srp-target: Retry when QP creation fails with ENOMEM

That's really a terrible record.

So until you're able to demonstrate publicly to me and the LIO community that you do have good intentions, and not trying to rehash the same tired old nonsense and willful ignorance, please stop throwing out these generic topics as a branding exercise.

There are much more interesting and important topics at LSF to discuss.