On Sun, 2011-06-19 at 01:55 +0900, FUJITA Tomonori wrote:

On Mon, 30 May 2011 15:09:49 +0200
Christoph Hellwig [off-list ref] wrote:

quoted

On Sun, May 29, 2011 at 11:49:08AM -0700, Linus Torvalds wrote:

quoted

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.

quoted

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