James Bottomley wrote:
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.
There is another aspect that I look at: portability to
the user space of Linux and other operating systems.
Are there C99 or POSIX equivalents of get_unaligned_be64()?
Recently sg_read_block_limits was contributed to sg3_utils.
Its author found a novel solution to this "problem" with
network stack calls: ntohl() and friends. So I ran with it
until I found it broke my builds in the MinGW environment
for Windows. Rather than put in conditional compiles and
wonder if my MinGW executables would get bloated, I opted
to go back to what has worked for the last 25 years.
Doug Gilbert
--
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
