From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladislav Bolkhovitin Subject: Re: [Stgt-devel] Question for pass-through target design Date: Tue, 08 May 2007 09:51:43 +0400 Message-ID: <46400FEF.5080109@vlnb.net> References: <463F36AC.3010207@vlnb.net> <20070507182837E.fujita.tomonori@lab.ntt.co.jp> <463F455B.3000209@vlnb.net> <20070508003734T.fujita.tomonori@lab.ntt.co.jp> <463F5952.9010803@vlnb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-relay-02.mailcluster.net ([85.249.135.243]:45849 "EHLO mail-relay-02.mailcluster.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755255AbXEHFvr (ORCPT ); Tue, 8 May 2007 01:51:47 -0400 In-Reply-To: <463F5952.9010803@vlnb.net> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: FUJITA Tomonori Cc: stgt-devel@lists.berlios.de, scst-devel@lists.sourceforge.net, linux-scsi@vger.kernel.org Vladislav Bolkhovitin wrote: > FUJITA Tomonori wrote: > >> From: Vladislav Bolkhovitin >> Subject: Re: [Stgt-devel] Question for pass-through target design >> Date: Mon, 07 May 2007 19:27:23 +0400 >> >> >>> FUJITA Tomonori wrote: >>> >>>> From: Vladislav Bolkhovitin >>>> Subject: Re: [Stgt-devel] Question for pass-through target design >>>> Date: Mon, 07 May 2007 18:24:44 +0400 >>>> >>>> >>>> >>>>> FUJITA Tomonori wrote: >>>>> >>>>> >>>>>>>>> It looks like the pass-through target support is currently >>>>>>>>> broken, at >>>>>>>>> least as I've checked for ibmvstgt, but I think it's a general >>>>>>>>> problem. >>>>>>>>> I wanted to check my assumptions and get ideas. >>>>>>>> >>>>>>>> >>>>>>>> Yeah, unfortunately, it works only with the iSCSI target driver >>>>>>>> (which >>>>>>>> runs in user space). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The code isn't allocating any memory to pass along to the sg >>>>>>>>> code to store >>>>>>>>> the result of a read or data for a write. Currently, dxferp >>>>>>>>> for sg_io_hdr >>>>>>>>> or dout_xferp/din_xferp for sg_io_v4 are assigned to the value >>>>>>>>> of uaddr, >>>>>>>>> which is set to 0 in kern_queue_cmd. With the pointer set to >>>>>>>>> NULL, >>>>>>>>> the pass-through target isn't going to function. Even if we >>>>>>>>> had memory >>>>>>>>> allocated, there isn't a means of getting data to be written >>>>>>>>> via sg down >>>>>>>>> this code path. >>>>>>>>> >>>>>>>>> What ideas are there as to how the data will get to user-space >>>>>>>>> so that >>>>>>>>> we can use sg? >>>>>>>> >>>>>>>> >>>>>>>> For kernel-space drivers, we don't need to go to user-space. We >>>>>>>> can do >>>>>>>> the pass-through in kernel space. I talked with James about this >>>>>>>> last >>>>>>>> year and he said that if the code is implemented cleanly, he would >>>>>>>> merges it into mainline. >>>>>>> >>>>>>> >>>>>>> We already have a pass-through in the kernel space for >>>>>>> kernel space drivers. It is the scsi_tgt* code. >>>>>> >>>>>> >>>>>> >>>>>> Could you elaborate more? >>>>>> >>>>>> What I meant that is that the kernel tgt code (scsi_tgt*) receives >>>>>> SCSI commands from one lld and send them to another lld instead of >>>>>> sending them to user space. >>>>> >>>>> >>>>> Although the approach of passing SCSI commands from a target LLD to an >>>>> initiator one without any significant interventions from the target >>>>> software looks to be nice and simple, you should realize how limited, >>>>> unsafe and illegal it is, since it badly violates SCSI specs. >>>> >>>> >>>> >>>> I think that 'implemented cleanly' means that one scsi_host is assigned >>>> to only one initiator. >>> >>> >>> Sorry, I don't fully understand you. If you mean you are going to >>> limit only one remote initiator per-target device, then, well, is it >>> even more limited (and limiting) or not? >> >> >> >> The target software assigns one scsi_host to only one remote >> initiator. For FC, NPIV works nicely. > > > OK, if such limitation is OK for your users, then I'm happy for you. And don't forget to tell them that they must not touch the exported devices locally ;) >> _______________________________________________ >> Stgt-devel mailing list >> Stgt-devel@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/stgt-devel >> > >