On Mon, 2013-10-07 at 17:51 -0400, Douglas Gilbert wrote: > 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: <SNIP> > >> * 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? > The assumption was that application clients receiving OPERATING PARAMETERS w/ SNLID=1 would know to only send list_id = 0 with list_id_usage = 11b. This assumption appears to have been incorrect. ;) So I'm fine with accepting non zero ListIDs when reporting SNLID=1, as long as there is no hard requirement on the copy server for tracking + rejecting already in use ListIDs when processing list_id_usage != 11b, while reporting SNLID=1. --nab -- 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
