On Wed, 2008-10-29 at 17:13 -0500, James Bottomley wrote: > > > No ... as I've said several times now, there's a debate going on about > > > what we're supposed to be doing with all of this (either putting it in > > > SCSI, pulling it out or just using the inline notation. > > > > If I knew what the terrible word "it" is replacing, I'd know what the > > above sentence means. > > It being the correct way to handle multibyte SCSI problems. > > > I'm kinda struggling to imagine why there's controversy, really. scsi > > has a private implementation of something which core kernel provides. > > Zap! > > The main problems with the above are that a lot of people don't > necessarily think Big Endian when they see SCSI (even though it's a BE > bus), so the get_unaligned_beXX looks strange, and secondly most of the > arrays we operate on are simple u8 ones, so sparse gets annoyed about > sending a non BE quantity through a BE conversion ... I bet it even does > this for the above patch. It does not, the get_unaligned_* family is not typesafe (takes a void *) as lots of people have u8 arrays or similar. Even though it probably should be. > > > > I'm not putting > > > a patch like this in until we at least get some consensus. > > > > I'll hang onto it, so there's nowhere to hide... > > OK. > Did you ever have some time to think about my suggestion regarding defining some common packed structs for the different command formats taht could be endian-annotated, then use the unaligned helpers against pointers to these structs...so sparse would actually spot endian mixups in scsi thereafter? 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
