Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759015AbYLKW4g (ORCPT ); Thu, 11 Dec 2008 17:56:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759162AbYLKWzR (ORCPT ); Thu, 11 Dec 2008 17:55:17 -0500 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]:35733 "HELO smtp115.sbc.mail.sp1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1759096AbYLKWzN (ORCPT ); Thu, 11 Dec 2008 17:55:13 -0500 X-YMail-OSG: OJnbRxoVM1m7Cr2a2zP0z.ffRE164YO2.hnUFzrOEsEuVWkGqs2qVh.YaGOZ5ceqPwEIEpVF8RHTp0LMEQRmdk9ZO3Ag10Cq04miIxZbn8wjizT.vxwCsgQbQrVsCqms7qr6rPAjNDOkY1bDa8FWQKNHCS0UyL5ZxHgANIZggbz73jdwDUp58yWIswU- X-Yahoo-Newman-Property: ymail-3 Subject: Re: [PATCH][RFC 21/23]: iSCSI target driver From: "Nicholas A. Bellinger" To: Vladislav Bolkhovitin Cc: linux-scsi@vger.kernel.org, James Bottomley , Andrew Morton , FUJITA Tomonori , Mike Christie , Jeff Garzik , Boaz Harrosh , Linus Torvalds , linux-kernel@vger.kernel.org, scst-devel@lists.sourceforge.net, Bart Van Assche , netdev@vger.kernel.org, Rafiu Fakunle In-Reply-To: <49401205.8010207@vlnb.net> References: <494009D7.4020602@vlnb.net> <49401205.8010207@vlnb.net> Content-Type: text/plain Date: Thu, 11 Dec 2008 14:55:09 -0800 Message-Id: <1229036109.4153.585.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4319 Lines: 91 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). 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 > --- > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/