[Stgt-devel] Question for pass-through target design

Vladislav Bolkhovitin vst
Mon May 7 17:27:23 CEST 2007


FUJITA Tomonori wrote:
> From: Vladislav Bolkhovitin <vst at vlnb.net>
> 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?

> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel
> 




More information about the stgt mailing list