From: Bart Van Assche <bart.vanassche@sandisk.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Cc: target-devel <target-devel@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] LIO/SCST Merger
Date: Wed, 27 Jan 2016 10:19:12 -0800 [thread overview]
Message-ID: <56A90A20.3020101@sandisk.com> (raw)
In-Reply-To: <1453918104.2322.26.camel@HansenPartnership.com>
On 01/27/2016 10:08 AM, James Bottomley wrote:
> On Wed, 2016-01-27 at 09:54 -0800, Bart Van Assche wrote:
>> 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.
>
> 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).
Thanks,
Bart.
next prev parent reply other threads:[~2016-01-27 18:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 17:54 [LSF/MM TOPIC] LIO/SCST Merger Bart Van Assche
2016-01-27 18:08 ` [Lsf-pc] " James Bottomley
2016-01-27 18:19 ` Bart Van Assche [this message]
2016-01-27 18:31 ` James Bottomley
2016-01-28 6:36 ` Nicholas A. Bellinger
2016-01-28 9:01 ` Christoph Hellwig
2016-01-28 16:24 ` Sagi Grimberg
2016-01-28 16:47 ` [Lsf-pc] " James Bottomley
2016-01-28 15:34 ` Bart Van Assche
2016-02-01 2:44 ` Alex Gorbachev
2016-01-29 2:57 ` Vladislav Bolkhovitin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A90A20.3020101@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.