[stgt] [PATCH] Add an array that describes which opcodes are supported by the RDWR and SHEEPDOG backends.

[ronnie sahlberg]

On Wed, Nov 6, 2013 at 11:07 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Wed, 30 Oct 2013 18:44:19 -0700
> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> On Sun, Oct 20, 2013 at 6:34 PM, FUJITA Tomonori
>> <fujita.tomonori at lab.ntt.co.jp> wrote:
>> > On Sat, 12 Oct 2013 07:38:59 -0700
>> > Ronnie Sahlberg <ronniesahlberg at gmail.com> wrote:
>> >
>> >> While RDWR supports all SBC opcodes that TGTD implement SHEEPDOG
>> >> only supports a subset and lacks the following opcodes:
>> >>             WRITE_VERIFY10/12/16 VERIFY10/12/16 PREFETCH10/16
>> >>             WRITE_SAME10/16 UNMAP and ORWRITE
>> >>
>> >> This allows backends to specify which opcodes it is prepared to process
>> >> and which commands should fail with invalid op code
>> >> and allows SHEEPDOG backed LUNs to respond with INVALID_OP_CODE
>> >> correctly.
>> >>
>> >> This is most useful for block devices where we have several different backens
>> >> and where some backends only support a subset of the commands
>> >>
>> >> Signed-off-by: Ronnie Sahlberg <ronniesahlberg at gmail.com>
>> >> ---
>> >>  usr/bs.c          |    8 ++++++++
>> >>  usr/bs_rdwr.c     |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>  usr/bs_sheepdog.c |   38 ++++++++++++++++++++++++++++++++++++++
>> >>  usr/scsi.c        |    6 ++++++
>> >>  usr/tgtd.h        |    1 +
>> >>  5 files changed, 104 insertions(+), 0 deletions(-)
>> >
>> > Why backend store's bs_cmd_submit cannot return a proper error and
>> > sbr_rc returns that error to an initiator?
>>
>>
>> It could, but this way it is more explicit which opcodes are
>> available, and a simple compare of the array between opcodes
>> makes it easy for non-bs_rdwr backend developers to see the delta
>> between their backend and rdwr.
>>
>> A second reason is for a followup patch.
>> The followup patch will use this array so that it can prune which
>> opcodes to report back for the REPORT_SUPPORTED_OPCODE opcode.
>> So that when you issue that command to a sheepdog LUN  you get a
>> pruned list back that only lists the opcodes that sheepdog supports.
>
> I see, thanks. Using the bitmaps is simpler than the array of char if
> you calculate delta and such?

I think using the array with opcode names is simpler for a human to
comparing when reading the sourcecode.


I had a bitmap of 32 bytes, one bit for each opcode,   and I also
tried using an array of 256 bytes, one byte 0/1 for each opcode
but it was horrible to read from a human standpoint.

When reading the code and the bitmap/array it was very difficult to
see which opcodes were supported and which were not
by just looking at the bits.
It was also errorprone and I did several mistakes when building the
bitmap manually.

This approach uses an array of opcodes, making it really easy for a
human to see which opcodes are supported and which are not.
Then I call bs_create_opcode_map() to convert this array into a
byte-array to make it efficient for tgtd to check if the opcodes are
supported or not.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html