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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Vladislav Bolkhovitin <vst@xxxxxxxx>
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 <vst@xxxxxxxx>
> > 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.
-
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux