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@xxxxxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
