On Thu, 2009-08-27 at 12:35 +0300, Boaz Harrosh wrote: > On 08/27/2009 09:58 AM, Martin K. Petersen wrote: > >>>>>> "Boaz" == Boaz Harrosh <bharrosh@xxxxxxxxxxx> writes: > > > >>> + *lba = (u64)cmd[19] | (u64)cmd[18] << 8 | > >>> + (u64)cmd[17] << 16 | (u64)cmd[16] << 24 | > >>> + (u64)cmd[15] << 32 | (u64)cmd[14] << 40 | > >>> + (u64)cmd[13] << 48 | (u64)cmd[12] << 56; > > > > Boaz> get_unaligned_be64() > > > > As you noticed further down in that patch I do generally use the > > get_unaligned_* macros in "my own" code. > > > > However, when I update somebody else's code I try to match the existing > > style. And in this case rest of get_data_transfer_info() is using > > explicit shifts and to me it looks absolutely horrendous to mix the two. > > > > I generally avoid mixing cleanups and new functionality. I don't have a > > problem with switching over to the macros, but in that case I think the > > whole function should be updated. And that should be an orthogonal > > patch. > > > > I don't know. For me it is like checkpatch. I do not submit code over 80 > chars even if surrounding code does. "The new code rule". I'd take that as a guideline rather than a rule ... Especially when lindent will generate 80 column long function templates over tens of lines squashing about five letters per line ... > I generally agree with what you say but I think there is a balance. > Personally, I think this is over the balance point, but it's your call. 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. James -- 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
