On 13-10-07 05:00 PM, Nicholas A. Bellinger wrote:
On Sun, 2013-10-06 at 20:03 +0200, Thomas Glanzmann wrote:
Hello Nab,
Doug (on CC) asked me to try ddpt[1] on the target code and it failed
because list_id was 1. The linux target code expects it to be 0. Doug
did not like the sense code sent back:
* drivers/target/target_core_xcopy.c line 907
sense_reason_t target_do_xcopy(struct se_cmd *se_cmd)
...
list_id = p[0];
if (list_id != 0x00) {
pr_err("XCOPY with non zero list_id: 0x%02x\n",
list_id);
goto out;
}
...
out:
if (p)
transport_kunmap_data_sg(se_cmd);
kfree(xop);
return TCM_INVALID_CDB_FIELD;
}
* Douglas Gilbert <dgilbert@xxxxxxxxxxxx> [2013-10-06 19:37]:
With SCSI sense data the target should:
a) give the correct ASC/ASCQ code "Invalid field in parameter list"
Fixing that up now, and will send out a patch shortly.
b) point to the byte (and bit within that byte)
that it objects to (and also say whether that
byte is cdb or parameter list).
Mmmm, that one is going to take alot more effort to implement, as we've
not a way currently to propagate up this value separate from
sense_reason_t.
The b) can be considered as optional; "good to have".
I think Seagate do it in their SCSI disks (SAS, FC).
From the application client point of view, with something
like the EXTENDED_COPY parameter list, there are a lot
of fields to choose from.
And the list_id, the target implementation only seems
to accept 0. Hannes Reinecke defaulted that to 1 and
I guess he had a good reason. Looking at spc4r36j.pdf
list_id==0 has a special meaning in one context (i.e.
when list_id_usage==3). I can understand the target
not accepting overlapping XCOPYs but why constrain
the application client to only use list_id 0?
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
