Date:	Mon, 25 Jul 2011 13:42:58 -0700
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Andy Grover <agrover@...hat.com>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
	Roland Dreier <roland@...estorage.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 08/13] iscsi-target: Add CHAP Authentication
	support	using libcrypto

On Mon, 2011-07-25 at 12:31 -0700, Andy Grover wrote:
> On 07/23/2011 09:41 PM, Nicholas A. Bellinger wrote:
> > While I apperciate Mike's input here, I'll leave the final word to Andy
> > and Christoph who have been primarly driving iscsi-target v4.1
> > development and are the guys who have their fingers deepest in the code.
> 
> I appreciate that, but hch and I have been working on cleaning up the
> main datapath; I personally haven't needed to familiarize myself with
> the auth code at all so far. That said, I happen to think you are
> correct, and am in favor of accepting the code as is, with in-kernel
> auth. I wasn't 100% sure from reading Mike's response but it sounded
> like he was saying he'd be ok with in-kernel auth since it would make
> handling hw iscsi targets easier.
> 

....

> (BTW I think the arguments about backwards compatibility with existing
> rtslib or pre-kernel-acceptance versions are not persuasive and a
> distraction from the real technical discussion. Linux has a very strong
> stable-user-api tenet, but we should commit to support stable APIs that
> are reviewed and accepted in the kernel, and not be limited by
> compatibility with prior out-of-kernel versions.)
> 

What I was trying to say here is we currently have a consistent
userspace library for the two default iscsi-target cases that is
completely driven by python userspace code.  We use rtslib to mask the
possible future changes (and breakage) to the target kernel api
(configfs) to avoid direct breakage with apps using the library, as well
as being able to gracefully add new API functionality using the
modern /var/target/spec/ layout that thus far has been fully native
using /sys/kernel/config/target/ (eg: no external userspace C code)

Yes, we do expect to have to change rtslib as neccessary in order to
support new features including the optional to implement fabric
dependent authentication methods.  How that looks is larely dependent on
the interaction with configfs, and what extra userspace daemons need to
be involved.  What I am very eager to avoid is more userspace dependence
for the default login cases that everyone will be using for v3.1.
 
> > But all that said, there is still one person who has the real final word
> > here, and he's made it clear how he feels about this type of kernel/user
> > split.
> 
> Well that's great and all - I would just emphasize we're all going to be
> working on this code cooperatively for a long time to come. More time
> spent discussing technical issues to where we can all reach a grumbling
> consensus will ultimately bear more fruit than appeals to the Hierarchy.
> 

Yes, but the specific discussion for 'optional to implement' is low on
the priority list now as we don't have iSCSI clients that use it for
v3.1.  So I am very happy to move forward for v3.2 and start adding
these as necessary, and would even consider reviving the old
AuthMethod=SRP code for LIO-Target 2.x if folks are willing to help on
the open-iscsi side to make this happen.

But aside from this particular bit of code, the main concern here has
really been the discussion to move the default non authenticated paths
from the kernel and into single threaded userspace code, when the
current /sys/kernel/config/target/iscsi/ is capable of configuring
10,000+ endpoints individually.  This point I am very firm on from
having to develop a fully dynamic control plane over the years with out
of tree and pre configfs LIO-Target code, and is what I think what makes
the most sense technically moving forward with v4.1 iscsi-target code.

Thanks,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists