On 08/27/2009 05:30 PM, James Bottomley wrote: > On Thu, 2009-08-27 at 17:20 +0300, Boaz Harrosh wrote: >> On 08/27/2009 04:41 PM, James Bottomley wrote: >>> >>> The general rule is not to confuse coding styles, so the correct way to >>> add stuff is to use the existing conventions in the file. You can >>> optionally convert the entire style if necessary. However, for these >>> get_cpu_be macros, there's no real benefit other than saving typing, so >>> a global conversion effort simply isn't worth it. >>> >> >> This is not right. The get_cpu_be macros are ten fold faster and smaller >> on all the platforms we ever use. I'm talking about 16-96 to 1 for a 64 bit >> operation. > > Assembly comparisons didn't bear this out the last time I looked; what > changed? > I'm not sure what test you made. But for instance on x86_64 which has unaligned cpu support, the get_unaligned_be64 is a simple SWAB instructions as opposed to 8 "or" + 8 "shift". Not to mention BE systems which do nothing (memcpy) >> Not to mention the heart attack it gives me every time. Is that index go down >> or up? the shifts go bigger or smaller? even just for that I would wrap them, >> triple check, and never use anything else. But the stronger fact of the matter >> is that I don't think there is a single used ARCH that does shifts anymore. > > OK, but for those of us who read the standards, they explicitly specify > byte offset fields for everything, so cmnd[n] does map exactly to that, > so I find the fully folded out form easier to read and compare with the > relevant standard text. > > That's why I'm not mandating anything other than keep the styles > consistent per file. You're free to use whatever you like in your > files. > > James > > Boaz -- 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
