FUJITA Tomonori wrote:
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.
OK, if such limitation is OK for your users, then I'm happy for you.
_______________________________________________
Stgt-devel mailing list
Stgt-devel@xxxxxxxxxxxxxxxx
https://lists.berlios.de/mailman/listinfo/stgt-devel
-
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
