[GIT PULL] iscsi-target: Merge for .40-rc1

[GIT PULL] iscsi-target: Merge for .40-rc1

[Nicholas A. Bellinger]

Hi Linus,

This is a GIT PULL request for the initial merge of the iscsi-target
fabric driver for mainline target core v4.0 infrastructure.

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6.git for-40-iscsi-target

This series has been made against the following linux-2.6.git HEAD:

commit dc7acbb2518f250050179c8581a972df3b6a24f1
Merge: f01e1af 4bf0ff2
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu May 26 19:01:15 2011 -0700

    Merge branch 'upstream/tidy-xen-mmu-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen

This code has undergone a number of review cycles on linux-scsi over the
last six months by Christoph, Mike and other interested folks.  This has
included a number of cleanups to follow mainline conventions, and
conversion to use mainline include/scsi/iscsi_proto.h RFC definitions.
There has been an good amount of testing feedback on this code so far,
and with the LIO communities help we have been able to resolve the
reported cleanup/conversion regressions, and fix one long-standing
shutdown bug.

Unfortuately James and I have been unable to come to an aggreement on
implementation details wrt to proper kernel/user split ahead of his
final SCSI pull for .40.  I have no interest to take the mainline
iscsi-target development effort in this direction again, so I am
offically committing to you to support iscsi-target in good-faith
together with rtslib community edition moving forward.  I am also
committing to extending iscsi-target to address the non-standard
authentication pieces that James has mentioned, but by the time .40
ships we are still not going to have iSCSI clients that actually support
them.

I believe that Christoph is happy with the current iscsi-target code for
an initial merge now, and am asking for the merge to avoid slipping
(again) for this type of 'mass-market' code that has a large audience,
and poses minimal risk considering the small amount of external changes.

Finally, please note for convience this branch contains the six .40
target core patches in James's most recent SCSI PULL request that need
to be merged ahead of iscsi-target.  There where posted here:

[PATCH 0/6] target: .40 bugfixes+changes (round 1)
http://marc.info/?l=linux-kernel&m=130586157027018&w=2

Please considering merging for .40-rc1, and please let me know if you
have any questions.

Thank you,

Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>

Nicholas Bellinger (3):
  iscsi: Resolve iscsi_proto.h naming conflicts with
    drivers/target/iscsi
  iscsi: Add Serial Number Arithmetic LT and GT into iscsi_proto.h
  iscsi-target: Add iSCSI fabric support for target v4

 drivers/infiniband/ulp/iser/iser_initiator.c      |    2 +-
 drivers/scsi/be2iscsi/be_main.h                   |    4 +-
 drivers/scsi/bnx2i/bnx2i_hwi.c                    |    8 +-
 drivers/scsi/libiscsi.c                           |   22 +-
 drivers/target/Kconfig                            |    1 +
 drivers/target/Makefile                           |    1 +
 drivers/target/iscsi/Kconfig                      |   18 +
 drivers/target/iscsi/Makefile                     |   20 +
 drivers/target/iscsi/iscsi_target.c               | 4963 +++++++++++++++++++++
 drivers/target/iscsi/iscsi_target.h               |   42 +
 drivers/target/iscsi/iscsi_target_auth.c          |  496 ++
 drivers/target/iscsi/iscsi_target_auth.h          |   31 +
 drivers/target/iscsi/iscsi_target_configfs.c      | 1925 ++++++++
 drivers/target/iscsi/iscsi_target_configfs.h      |    7 +
 drivers/target/iscsi/iscsi_target_core.h          |  860 ++++
 drivers/target/iscsi/iscsi_target_datain_values.c |  532 +++
 drivers/target/iscsi/iscsi_target_datain_values.h |   12 +
 drivers/target/iscsi/iscsi_target_debug.h         |  113 +
 drivers/target/iscsi/iscsi_target_device.c        |   88 +
 drivers/target/iscsi/iscsi_target_device.h        |    9 +
 drivers/target/iscsi/iscsi_target_erl0.c          | 1005 +++++
 drivers/target/iscsi/iscsi_target_erl0.h          |   15 +
 drivers/target/iscsi/iscsi_target_erl1.c          | 1306 ++++++
 drivers/target/iscsi/iscsi_target_erl1.h          |   26 +
 drivers/target/iscsi/iscsi_target_erl2.c          |  483 ++
 drivers/target/iscsi/iscsi_target_erl2.h          |   18 +
 drivers/target/iscsi/iscsi_target_login.c         | 1233 +++++
 drivers/target/iscsi/iscsi_target_login.h         |   12 +
 drivers/target/iscsi/iscsi_target_nego.c          | 1068 +++++
 drivers/target/iscsi/iscsi_target_nego.h          |   17 +
 drivers/target/iscsi/iscsi_target_nodeattrib.c    |  264 ++
 drivers/target/iscsi/iscsi_target_nodeattrib.h    |   14 +
 drivers/target/iscsi/iscsi_target_parameters.c    | 1906 ++++++++
 drivers/target/iscsi/iscsi_target_parameters.h    |  269 ++
 drivers/target/iscsi/iscsi_target_seq_pdu_list.c  |  665 +++
 drivers/target/iscsi/iscsi_target_seq_pdu_list.h  |   86 +
 drivers/target/iscsi/iscsi_target_stat.c          |  950 ++++
 drivers/target/iscsi/iscsi_target_stat.h          |   64 +
 drivers/target/iscsi/iscsi_target_tmr.c           |  850 ++++
 drivers/target/iscsi/iscsi_target_tmr.h           |   14 +
 drivers/target/iscsi/iscsi_target_tpg.c           |  760 ++++
 drivers/target/iscsi/iscsi_target_tpg.h           |   41 +
 drivers/target/iscsi/iscsi_target_tq.c            |  552 +++
 drivers/target/iscsi/iscsi_target_tq.h            |   88 +
 drivers/target/iscsi/iscsi_target_util.c          | 1868 ++++++++
 drivers/target/iscsi/iscsi_target_util.h          |   98 +
 include/scsi/iscsi_proto.h                        |   68 +-
 47 files changed, 22860 insertions(+), 34 deletions(-)
 create mode 100644 drivers/target/iscsi/Kconfig
 create mode 100644 drivers/target/iscsi/Makefile
 create mode 100644 drivers/target/iscsi/iscsi_target.c
 create mode 100644 drivers/target/iscsi/iscsi_target.h
 create mode 100644 drivers/target/iscsi/iscsi_target_auth.c
 create mode 100644 drivers/target/iscsi/iscsi_target_auth.h
 create mode 100644 drivers/target/iscsi/iscsi_target_configfs.c
 create mode 100644 drivers/target/iscsi/iscsi_target_configfs.h
 create mode 100644 drivers/target/iscsi/iscsi_target_core.h
 create mode 100644 drivers/target/iscsi/iscsi_target_datain_values.c
 create mode 100644 drivers/target/iscsi/iscsi_target_datain_values.h
 create mode 100644 drivers/target/iscsi/iscsi_target_debug.h
 create mode 100644 drivers/target/iscsi/iscsi_target_device.c
 create mode 100644 drivers/target/iscsi/iscsi_target_device.h
 create mode 100644 drivers/target/iscsi/iscsi_target_erl0.c
 create mode 100644 drivers/target/iscsi/iscsi_target_erl0.h
 create mode 100644 drivers/target/iscsi/iscsi_target_erl1.c
 create mode 100644 drivers/target/iscsi/iscsi_target_erl1.h
 create mode 100644 drivers/target/iscsi/iscsi_target_erl2.c
 create mode 100644 drivers/target/iscsi/iscsi_target_erl2.h
 create mode 100644 drivers/target/iscsi/iscsi_target_login.c
 create mode 100644 drivers/target/iscsi/iscsi_target_login.h
 create mode 100644 drivers/target/iscsi/iscsi_target_nego.c
 create mode 100644 drivers/target/iscsi/iscsi_target_nego.h
 create mode 100644 drivers/target/iscsi/iscsi_target_nodeattrib.c
 create mode 100644 drivers/target/iscsi/iscsi_target_nodeattrib.h
 create mode 100644 drivers/target/iscsi/iscsi_target_parameters.c
 create mode 100644 drivers/target/iscsi/iscsi_target_parameters.h
 create mode 100644 drivers/target/iscsi/iscsi_target_seq_pdu_list.c
 create mode 100644 drivers/target/iscsi/iscsi_target_seq_pdu_list.h
 create mode 100644 drivers/target/iscsi/iscsi_target_stat.c
 create mode 100644 drivers/target/iscsi/iscsi_target_stat.h
 create mode 100644 drivers/target/iscsi/iscsi_target_tmr.c
 create mode 100644 drivers/target/iscsi/iscsi_target_tmr.h
 create mode 100644 drivers/target/iscsi/iscsi_target_tpg.c
 create mode 100644 drivers/target/iscsi/iscsi_target_tpg.h
 create mode 100644 drivers/target/iscsi/iscsi_target_tq.c
 create mode 100644 drivers/target/iscsi/iscsi_target_tq.h
 create mode 100644 drivers/target/iscsi/iscsi_target_util.c
 create mode 100644 drivers/target/iscsi/iscsi_target_util.h

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[Linus Torvalds]

Gaah.

I don't feel confident or motivated enough about iscsi-target, so
after some (little) thought I ended up not pulling this. I really need
a lot of acks from people who actually work on and care about SCSI,
and right now I feel like with me being away for the next week, I
can't handle it.

I just don't want to be in the situation where I pull something that
is apparently contentious in the SCSI space in general, but that's
_particularly_ true this release. So I'm afraid that this essentially
got pushed out to the next release.

                    Linus

On Fri, May 27, 2011 at 7:59 PM, Nicholas A. Bellinger
<nab@linux-iscsi.org> wrote:
> Hi Linus,
>
> This is a GIT PULL request for the initial merge of the iscsi-target
> fabric driver for mainline target core v4.0 infrastructure.
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6.git for-40-iscsi-target
>
> This series has been made against the following linux-2.6.git HEAD:
>
> commit dc7acbb2518f250050179c8581a972df3b6a24f1
> Merge: f01e1af 4bf0ff2
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu May 26 19:01:15 2011 -0700
>
>    Merge branch 'upstream/tidy-xen-mmu-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen
>
> This code has undergone a number of review cycles on linux-scsi over the
> last six months by Christoph, Mike and other interested folks.  This has
> included a number of cleanups to follow mainline conventions, and
> conversion to use mainline include/scsi/iscsi_proto.h RFC definitions.
> There has been an good amount of testing feedback on this code so far,
> and with the LIO communities help we have been able to resolve the
> reported cleanup/conversion regressions, and fix one long-standing
> shutdown bug.
>
> Unfortuately James and I have been unable to come to an aggreement on
> implementation details wrt to proper kernel/user split ahead of his
> final SCSI pull for .40.  I have no interest to take the mainline
> iscsi-target development effort in this direction again, so I am
> offically committing to you to support iscsi-target in good-faith
> together with rtslib community edition moving forward.  I am also
> committing to extending iscsi-target to address the non-standard
> authentication pieces that James has mentioned, but by the time .40
> ships we are still not going to have iSCSI clients that actually support
> them.
>
> I believe that Christoph is happy with the current iscsi-target code for
> an initial merge now, and am asking for the merge to avoid slipping
> (again) for this type of 'mass-market' code that has a large audience,
> and poses minimal risk considering the small amount of external changes.
> [...]

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[Nicholas A. Bellinger]

On Sun, 2011-05-29 at 11:49 -0700, Linus Torvalds wrote:
> Gaah.
> 
> I don't feel confident or motivated enough about iscsi-target, so
> after some (little) thought I ended up not pulling this. I really need
> a lot of acks from people who actually work on and care about SCSI,
> and right now I feel like with me being away for the next week, I
> can't handle it.
> 
> I just don't want to be in the situation where I pull something that
> is apparently contentious in the SCSI space in general, but that's
> _particularly_ true this release. So I'm afraid that this essentially
> got pushed out to the next release.
> 

Hi again Linus,

Thanks for your consideration here.  I understand your concern and the
time pressures involved that make this difficult for you to merge this
round.

To clarify one point however, the contentious piece in question between
James and myself is something that I am not willing to compromise on for
this (or the next) round considering the serious technical implications
of doing so as discussed in the PATCH-v5 thread.

My real frustration here is the fact that this is the second time in as
many merge windows where at the very last minute this same point has
been raised to effectively delay the merging of this code.  There have
been many folks ready to sign-off on the current design (including
upstream distro folks), and the number of target patches from full time
developers like Andy have been piling up waiting for this to be merged.

So that said, aside from my differences of opinion on this particular
topic with James wrt to iscsi-target, the bigger issue here having to go
through the SCSI tree for all drivers/target/ related changes.  This is
really starting to slow down the number of target core changes getting
to mainline, and is causing the lio-core-2.6.git tree (that full time
developers like Andy are using) to quickly diverge from mainline.

So, I am asking for you to consider start pulling directly from .41 and
onwards for target core pieces now that drivers/target/ has finally been
added to MAINTAINERS.  I am not interested in trying to push anything
related to drivers/scsi/ outside of the SCSI tree, but for pieces of
target core that are not directly related to drivers/scsi/, it would be
very helpful for you to start pulling directly in order to keep the
mainline target better in-sync with lio-core-2.6.git tree that full time
target developers are using and moving forward with.

Thank you,

--nab


>                     Linus
> 
> On Fri, May 27, 2011 at 7:59 PM, Nicholas A. Bellinger
> <nab@linux-iscsi.org> wrote:
> > Hi Linus,
> >
> > This is a GIT PULL request for the initial merge of the iscsi-target
> > fabric driver for mainline target core v4.0 infrastructure.
> >
> >  git://git.kernel.org/pub/scm/linux/kernel/git/nab/scsi-post-merge-2.6.git for-40-iscsi-target
> >
> > This series has been made against the following linux-2.6.git HEAD:
> >
> > commit dc7acbb2518f250050179c8581a972df3b6a24f1
> > Merge: f01e1af 4bf0ff2
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Thu May 26 19:01:15 2011 -0700
> >
> >    Merge branch 'upstream/tidy-xen-mmu-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen
> >
> > This code has undergone a number of review cycles on linux-scsi over the
> > last six months by Christoph, Mike and other interested folks.  This has
> > included a number of cleanups to follow mainline conventions, and
> > conversion to use mainline include/scsi/iscsi_proto.h RFC definitions.
> > There has been an good amount of testing feedback on this code so far,
> > and with the LIO communities help we have been able to resolve the
> > reported cleanup/conversion regressions, and fix one long-standing
> > shutdown bug.
> >
> > Unfortuately James and I have been unable to come to an aggreement on
> > implementation details wrt to proper kernel/user split ahead of his
> > final SCSI pull for .40.  I have no interest to take the mainline
> > iscsi-target development effort in this direction again, so I am
> > offically committing to you to support iscsi-target in good-faith
> > together with rtslib community edition moving forward.  I am also
> > committing to extending iscsi-target to address the non-standard
> > authentication pieces that James has mentioned, but by the time .40
> > ships we are still not going to have iSCSI clients that actually support
> > them.
> >
> > I believe that Christoph is happy with the current iscsi-target code for
> > an initial merge now, and am asking for the merge to avoid slipping
> > (again) for this type of 'mass-market' code that has a large audience,
> > and poses minimal risk considering the small amount of external changes.
> > [...]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[Christoph Hellwig]

On Sun, May 29, 2011 at 11:49:08AM -0700, Linus Torvalds wrote:
> I don't feel confident or motivated enough about iscsi-target, so
> after some (little) thought I ended up not pulling this. I really need
> a lot of acks from people who actually work on and care about SCSI,
> and right now I feel like with me being away for the next week, I
> can't handle it.
> 
> I just don't want to be in the situation where I pull something that
> is apparently contentious in the SCSI space in general, but that's
> _particularly_ true this release. So I'm afraid that this essentially
> got pushed out to the next release.

The main contention right now is wether to put the authentification
into kernel space or not.  Doing the slow path in userspace worked
out okay but not great on the initiator, but it has the potential
to become a nightmare worse than oprofile if the split ends up not
beeing perfect.

Given that we pretty well tested and working code that's used in lots
of production setups my vote is for taking it as-is unless someone can
actually show a prototype for a nicely working user/kernel split.

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[Bart Van Assche]

On Mon, May 30, 2011 at 3:09 PM, Christoph Hellwig <hch@lst.de> wrote:
> Given that we pretty well tested and working code that's used in lots
> of production setups my vote is for taking it as-is unless someone can
> actually show a prototype for a nicely working user/kernel split.

As far as I know such a user/kernel split has been implemented in both
IET and SCST and is working fine in both of these projects.

And here is another issue that still hasn't been resolved yet:
http://marc.info/?l=linux-scsi&m=129707890023739&w=2.

Bart.

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[Christoph Hellwig]

On Mon, May 30, 2011 at 05:13:22PM +0200, Bart Van Assche wrote:
> On Mon, May 30, 2011 at 3:09 PM, Christoph Hellwig <hch@lst.de> wrote:
> > Given that we pretty well tested and working code that's used in lots
> > of production setups my vote is for taking it as-is unless someone can
> > actually show a prototype for a nicely working user/kernel split.
> 
> As far as I know such a user/kernel split has been implemented in both
> IET and SCST and is working fine in both of these projects.

Which are unrelated codebases - if you want to offer a competing iSCSI
implementation for the core target framework we have in mainline based
on the codebase go ahead.

> And here is another issue that still hasn't been resolved yet:
> http://marc.info/?l=linux-scsi&m=129707890023739&w=2.

This is related to the software iSCSI fronted in what way?

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[Bart Van Assche]

On Tue, May 31, 2011 at 12:19 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, May 30, 2011 at 05:13:22PM +0200, Bart Van Assche wrote:
>> And here is another issue that still hasn't been resolved yet:
>> http://marc.info/?l=linux-scsi&m=129707890023739&w=2.
>
> This is related to the software iSCSI fronted in what way?

I see this as a design bug that affects the target core and all target
drivers. As far as I know nobody has started resolving this issue yet
nor is there agreement about how it has to be resolved.

Bart.

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[FUJITA Tomonori]

On Mon, 30 May 2011 15:09:49 +0200
Christoph Hellwig <hch@lst.de> wrote:

> On Sun, May 29, 2011 at 11:49:08AM -0700, Linus Torvalds wrote:
> > I don't feel confident or motivated enough about iscsi-target, so
> > after some (little) thought I ended up not pulling this. I really need
> > a lot of acks from people who actually work on and care about SCSI,
> > and right now I feel like with me being away for the next week, I
> > can't handle it.
> > 
> > I just don't want to be in the situation where I pull something that
> > is apparently contentious in the SCSI space in general, but that's
> > _particularly_ true this release. So I'm afraid that this essentially
> > got pushed out to the next release.
> 
> The main contention right now is wether to put the authentification
> into kernel space or not.  Doing the slow path in userspace worked
> out okay but not great on the initiator, but it has the potential
> to become a nightmare worse than oprofile if the split ends up not
> beeing perfect.

As I said earlier, the split is pretty simple for target code unlike
initiator code. Doing operations before SCSI nexus establishment in
userspace and then the kernel takes over nexuses. The information that
the user space needs for the login negotiation is exported via
configfs. Unlike open-iscsi split, the nexuses don't go back and forth
between user and kernel space.


> Given that we pretty well tested and working code that's used in lots
> of production setups my vote is for taking it as-is unless someone can
> actually show a prototype for a nicely working user/kernel split.

ok, I implemented something like that. It's not finished at all but
my open-iscsi box successfully logged in. The daemon just passes a file
descriptor to kernel space after the negotiation finishes.

ssh://master.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git lio-4.1-ud

The user space code is at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/tomo/iscsi-tcmd.git

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[James Bottomley]

On Sun, 2011-06-19 at 01:55 +0900, FUJITA Tomonori wrote:
> On Mon, 30 May 2011 15:09:49 +0200
> Christoph Hellwig <hch@lst.de> wrote:
> 
> > On Sun, May 29, 2011 at 11:49:08AM -0700, Linus Torvalds wrote:
> > > I don't feel confident or motivated enough about iscsi-target, so
> > > after some (little) thought I ended up not pulling this. I really need
> > > a lot of acks from people who actually work on and care about SCSI,
> > > and right now I feel like with me being away for the next week, I
> > > can't handle it.
> > > 
> > > I just don't want to be in the situation where I pull something that
> > > is apparently contentious in the SCSI space in general, but that's
> > > _particularly_ true this release. So I'm afraid that this essentially
> > > got pushed out to the next release.
> > 
> > The main contention right now is wether to put the authentification
> > into kernel space or not.  Doing the slow path in userspace worked
> > out okay but not great on the initiator, but it has the potential
> > to become a nightmare worse than oprofile if the split ends up not
> > beeing perfect.
> 
> As I said earlier, the split is pretty simple for target code unlike
> initiator code. Doing operations before SCSI nexus establishment in
> userspace and then the kernel takes over nexuses. The information that
> the user space needs for the login negotiation is exported via
> configfs. Unlike open-iscsi split, the nexuses don't go back and forth
> between user and kernel space.
> 
> 
> > Given that we pretty well tested and working code that's used in lots
> > of production setups my vote is for taking it as-is unless someone can
> > actually show a prototype for a nicely working user/kernel split.
> 
> ok, I implemented something like that. It's not finished at all but
> my open-iscsi box successfully logged in. The daemon just passes a file
> descriptor to kernel space after the negotiation finishes.
> 
> ssh://master.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git lio-4.1-ud
> 
> The user space code is at:
> ssh://master.kernel.org/pub/scm/linux/kernel/git/tomo/iscsi-tcmd.git

There's been a singular lack of comments on this.

To me, the code looks reasonable (at just over 200 lines for the socket
passing.  It's extensible to support arbitrary login protocols, and it
doesn't impact the fast path at all.

Now that we have the actual code, it's a lot cleaner even than I
imagined ... is there any objection simply to doing this?

James

Re: [GIT PULL] iscsi-target: Merge for .40-rc1

[Nicholas A. Bellinger]

On Sun, 2011-06-19 at 01:55 +0900, FUJITA Tomonori wrote:
> On Mon, 30 May 2011 15:09:49 +0200
> Christoph Hellwig <hch@lst.de> wrote:
> 
> > On Sun, May 29, 2011 at 11:49:08AM -0700, Linus Torvalds wrote:
> > > I don't feel confident or motivated enough about iscsi-target, so
> > > after some (little) thought I ended up not pulling this. I really need
> > > a lot of acks from people who actually work on and care about SCSI,
> > > and right now I feel like with me being away for the next week, I
> > > can't handle it.
> > > 
> > > I just don't want to be in the situation where I pull something that
> > > is apparently contentious in the SCSI space in general, but that's
> > > _particularly_ true this release. So I'm afraid that this essentially
> > > got pushed out to the next release.
> > 
> > The main contention right now is wether to put the authentification
> > into kernel space or not.  Doing the slow path in userspace worked
> > out okay but not great on the initiator, but it has the potential
> > to become a nightmare worse than oprofile if the split ends up not
> > beeing perfect.
> 
> As I said earlier, the split is pretty simple for target code unlike
> initiator code. Doing operations before SCSI nexus establishment in
> userspace and then the kernel takes over nexuses. The information that
> the user space needs for the login negotiation is exported via
> configfs. Unlike open-iscsi split, the nexuses don't go back and forth
> between user and kernel space.
> 
> 
> > Given that we pretty well tested and working code that's used in lots
> > of production setups my vote is for taking it as-is unless someone can
> > actually show a prototype for a nicely working user/kernel split.
> 
> ok, I implemented something like that. It's not finished at all but
> my open-iscsi box successfully logged in. The daemon just passes a file
> descriptor to kernel space after the negotiation finishes.
> 
> ssh://master.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git lio-4.1-ud
> 
> The user space code is at:
> ssh://master.kernel.org/pub/scm/linux/kernel/git/tomo/iscsi-tcmd.git

Hi Tomo and Co,

Just to clarify my position on your efforts here, as I do agree with
James that they deserve a reply, regardless of my personal thoughts..

My main problem was that I was not expecting a port of IET userspace to
lio-4.1 for the main -> default login control path, so it makes it very
difficult for me to consider this type of split when the userspace code
is AFAICT not aware of any dynamic changes to the iscsi-target control
plane in /sys/kernel/config/target/iscsi/, which makes it extremely
fragile in it's current state.

So that said, I would be willing to consider merging this type of code
as an EXPERIMENTAL feature into a lio-core-2.6.git working tree for you,
if:

*) It can be made completely optional, and the currently proposed v3.1
login path runs in-kernel as the default so that it can function
cooperatively in the same tree with my own 'optional to implement'
authentication efforts in LIO upstream.
*) You commit to producing a userspace daemon that is aware of dynamic
changes to the configfs layout by userspace driven within an individual
iscsi-target contexts.  I don't care if this is IET or LIO, but the
daemon cannot be static to configfs layout changes.
*) We consider the fully in-kernel approach with 10,000+ endpoint layout
configurations for the non authenticated (CSG=1) login path for the
large scale demo-mode public iscsi-target setups.

So with this we can both have what we want in LIO upstream working tree,
with little effect on the current in-kernel code proposed for v3.1.
This is what I care most about personally and am committing to support
for v3.1 and beyond, and must be absoulutely rock solid for all possible
dynamic configfs configuration changes.  This is the control plane
design that I believe has been presented in the v3.1-rc1 merge request.

Thanks,

--nab