lkml.org 
[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH-v5 07/13] iscsi-target: Add iSCSI Login Negotiation + Parameter logic
From
Date
On Thu, 2011-05-26 at 11:46 -0500, James Bottomley wrote:
> On Thu, 2011-05-19 at 20:37 -0700, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger <nab@linux-iscsi.org>
> >
> > This patch adds the princple RFC-3720 compatiable iSCSI Login
> > phase negotiation for iscsi_target_mod. This also includes the
> > target RX/TX thread queue logic which is called directly from iSCSI
> > login associated code.
> >
> > Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>
>
> I thought the upshot of the thread with Tomo was that we wouldn't be
> doing all of this in-kernel. Where's the userspace upcall for this?
>

The technical reasons why I want to avoid this have not changed for the
1) authentication disabled and 2) 'required-to-implement' CHAP
authentication cases. These where discussed at the bottom of the thread
from March with Tomo-san here:

http://marc.info/?l=linux-scsi&m=130108812405710&w=2

As mentioned, I am open to adding a userspace upcall for authentication
payloads post merge in order to support the 'optional-to-implement'
authentication cases. However, pushing the above two cases out to
userspace really does add unnecessary complexity and limitiations that I
want to avoid for the default iSCSI login cases.

It also would break existing rtslib/rtsadmin-v2 userspace code, and
require a userspace daemon be aware of the necessary initiator NodeACL
information and keep the current configuration state in sync between
kernel + userspace. The current code avoids this type of mess all
together for the default cases, and I still only see downsides and
endless maintainability headaches and delays for going back to this type
of design for a kernel-level iscsi-target.

--nab




\
 
 \ /
  Last update: 2011-05-26 21:17    [W:0.094 / U:11.164 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site