Re: [PATCH] scsi: sd_dif.c use unaligned access helpers

[Harvey Harrison <harvey.harrison@gmail.com>]

On Sat, 2008-07-26 at 08:26 -0400, Martin K. Petersen wrote:
> >>>>> "Harvey" == Harvey Harrison <harvey.harrison@gmail.com> writes:
> 
> Harvey> So who cares what the spec says, the code is treating it as a
> Harvey> host-order u16 everywhere.  Similarly for the ref_tag.
> 
> Hold on.  We don't know the personality of the ref_tag.
> 
> This is convoluted and I totally agree it's icky.
> 
> Each DIF tuple consists of 8 bytes.  The interpretation of those 8
> bytes depends on how the disk is formatted.  For Type 1, 2 and 3 the
> first two bytes contain the guard_tag, a big endian CRC of the data
> portion of the sector.  That part is easy.
> 
> The next two bytes are defined to be for use by the application client
> (i.e. OS).  The current SCSI spec doesn't say anything about the
> contents or how they should be interpreted.
> 
> The last four bytes (reference tag) are defined as a big endian entity
> for Type 1 and 2.  But with Type 3 the last four bytes become part of
> the opaque tag space.  You can view is as they get combined with the
> app tag to provide 6 bytes of space.

Ahh, reading what you originally wrote I see what you mean now.

> 
> IOW, for Type 1 + 2 the ref tag is big endian.  For Type 3 it is
> undefined.
> 
> Also, for DIF Type 4 that's currently being discussed the application
> tag will be used for a hash that's defined to be big endian.
> 
> So the problem is that the endianness depends on how the attached disk
> is formatted.
> 
> For now we can switch the app_tag to be host endian.  The only
> workaround I can think of for the ref_tag is to introduce struct
> sd_dif_tuple_type12 and struct sd_dif_tuple_type3 which use __be32 and
> u32 respectively.

That's probably not too bad of an idea.  Thanks for taking the time
to explain.

> 
> I'll muck with that later.  But first I have to finish my OLS
> slides...

Good luck.

Harvey