>>>>> "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. 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. I'll muck with that later. But first I have to finish my OLS slides... -- Martin K. Petersen Oracle Linux Engineering -- 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
