[lkml]   [2011]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.



     \ /
      Last update: 2011-07-25 22:55    [W:0.028 / U:49.368 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site