On Thu, 2008-12-11 at 14:55 -0800, Nicholas A. Bellinger wrote: > On Wed, 2008-12-10 at 22:01 +0300, Vladislav Bolkhovitin wrote: > > This patch contains iSCSI-SCST target driver. This driver is a heavily > > modified forked with all respects IET > > (http://iscsitarget.sourceforge.net). Modifications were aimed to make a > > clearer, more reviewable and maintainable code as well as to fix many > > problems and make many improvements. See > > http://scst.sourceforge.net/target_iscsi.html for more details. > > > > It has split user/kernel space architecture, where all management, > > sessions creation, parameters negotiation, etc. made in user space and > > data are transferred in the kernel space. Such architecture for iSCSI > > processing was many times acknowledged as the right one. Particularly, > > in-kernel iSCSI initiator (open-iscsi) has such architecture. > > > > Just as with the Open/iSCSI Initiator, IMHO I believe the split > architecture design is difficult both to improve, debug and maintain, > and provides *ZERO* additional benefit in the context of traditional > iSCSI target mode for doing login and connection/session setup in > userspace. > > Also, I appericate that you spent alot of time porting over IET code to > your engine, but during our previous discussion you did not seem > terribly interested in validation against core-iscsi-dv > (http://linux-iscsi.org/index.php/Core-iscsi-dv) to test RFC-3720 > interopt and stability. Because the Core-iSCSI Initiator supports every > possible parameter combination up to ErrorRecoveryLevel=0 defined in > RFC-3720, the Core-iSCSI-Dv tests can run badblocks (or any too) to > check data integrity for *EVERY* possible traditional iSCSI key > combination and functionality for your iSCSI-SCST work, and any type of > serious iSCSI-SCST production deployments. > > Until you can at least do that to prove both the stability and > completeness of your iSCSI Target stack up to RFC-3720 > ErrorRecoveryLevel=0, I don't think this code makes sense for any type > of mainline acceptance. Also, I would appericate if you could stop the > handwaving about MC/S and ErrorRecoveryLevel=2 as well. MC/S (multiple > connection paths for iSCSI/TCP, not necessary with multiple assoication > LIO-Target SCTP) and ERL=2 (OS independent fabric recovery) is available > in both RFC-3720 (Traditional iSCSI) and RFC-5045 (iSER for iWARP and > IB). > That was RFC-5046 for iSER note btw, RFC-5045 is the actual case for RDMA/DDP over TCP and the Stream Control Transfer Protocol (SCTP). Regards, --nab > Trying to argue against implementing the complete iSCSI RFC > functionality (like some folks did during the early Open/iSCSI days) > that customers and users *WANT* now is going to fall of deaf ears. > Please understand that they are going to be many, many different iSCSi > Initiators connecting to the upstream iSCSI Target Core infrastructure, > and trying to rush in an incomplete iSCSI Target $FABRIC_MOD > implementation benefits anyone. > > Regards, > > --nab > > > Signed-off-by: Vladislav Bolkhovitin <vst@xxxxxxxx> > > --- > > drivers/scst/iscsi-scst/Kconfig | 25 > > drivers/scst/iscsi-scst/Makefile | 6 > > drivers/scst/iscsi-scst/config.c | 597 +++++++ > > drivers/scst/iscsi-scst/conn.c | 488 +++++ > > drivers/scst/iscsi-scst/digest.c | 221 ++ > > drivers/scst/iscsi-scst/digest.h | 31 > > drivers/scst/iscsi-scst/event.c | 116 + > > drivers/scst/iscsi-scst/iscsi.c | 3066 ++++++++++++++++++++++++++++++++++++ > > drivers/scst/iscsi-scst/iscsi.h | 577 ++++++ > > drivers/scst/iscsi-scst/iscsi_dbg.h | 73 > > drivers/scst/iscsi-scst/iscsi_hdr.h | 517 ++++++ > > drivers/scst/iscsi-scst/nthread.c | 1522 +++++++++++++++++ > > drivers/scst/iscsi-scst/param.c | 263 +++ > > drivers/scst/iscsi-scst/session.c | 210 ++ > > drivers/scst/iscsi-scst/target.c | 306 +++ > > include/scst/iscsi_scst.h | 156 + > > include/scst/iscsi_scst_ver.h | 16 > > 17 files changed, 8190 insertions(+) > > > > The patch is too big to be submitted inline. You can find it in > > http://scst.sourceforge.net/patches/iscsi-scst.diff > > > > > > > > -- > > 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 > > > > -- > 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 > -- 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
