On Sat, 2008-07-26 at 08:26 -0400, Martin K. Petersen wrote: > >>>>> "Harvey" == Harvey Harrison <harvey.harrison@xxxxxxxxx> 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 -- 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
