Vladislav Bolkhovitin wrote:
FUJITA Tomonori wrote:
From: Vladislav Bolkhovitin <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
