On Mon, 2010-05-31 at 12:32 +0900, FUJITA Tomonori wrote:
> On Sun, 30 May 2010 12:36:18 +0300
> Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
>
> > > @@ -125,7 +141,7 @@ static int bs_sg_cmd_submit(struct scsi_cmd *cmd)
> > > set_cmd_async(cmd);
> > > else {
> > > eprintf("failed to start cmd 0x%p\n", cmd);
> > > - set_cmd_failed(cmd);
> > > + return set_cmd_failed(cmd);
> > > }
> > > return 0;
> > > }
> > > @@ -238,6 +254,7 @@ static int bs_sg_cmd_done(struct scsi_cmd *cmd)
> > > static struct backingstore_template sg_bst = {
> > > .bs_name = "sg",
> > > .bs_datasize = 0,
> > > + .bs_passthrough = 1,
> > > .bs_open = bs_sg_open,
> > > .bs_close = bs_sg_close,
> > > .bs_cmd_submit = bs_sg_cmd_submit,
> >
> > And again the Second patch should just fold into this one. And the final disposition will
> > just set the .bs_cmd_submit to the proper one.
>
> Hmm, that means this patchset adds new I/O code with sg (or
> bsg). That's not passthrough..
>
> I think that passthrough needs to overwrite some of struct
> device_type_template and modify target_cmd_queue().
Indeed. Expecting the passthrough to bypass the STGT port and CDB
emulation at the top of scsi_cmd_perform() would probably make sense
AFAICT.
So that said, at which spot in target_cmd_queue() would it make sense
for incoming struct scsi_cmd to be handled off for passthrough..?
Best,
--nab
--
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
