Hi Joe,
On Tue, 09 Nov 2010 01:59:44 -0800, Joe Perches wrote:
I'll fix these myself, no problem.
I've heard this argument many times, but it doesn't really hold
examination, I'm afraid. If nothing else, your patches are enforcing
the use of the module name as the log message prefix. So there's no
reason to grep for the message itself, when you can use "find" and
search for the module name 80 times faster.
Secondly, grep will find strings in binaries, and there it doesn't
matter if the string was split in the source file or not. If you
consider that grepping the whole kernel tree is acceptable
performance-wise, you probably don't mind processing the binary files
as well. The only drawback of this approach, I concede, is that it
assumes that the module in question has already been build locally. But
I doubt this is a problem in practice.
Thirdly, log messages aren't raw messages, they are format strings, so
grepping the sources for the output is never guaranteed to work in the
first place, split strings or not.
Fourthly, log messages aren't guaranteed to be unique over the kernel
tree, and as the tree grows, duplicates are more frequent.
And for completeness: if you really want to use grep, then yes, the
point at which the strings are split does matter. If you choose
carefully the split point, then it doesn't prevent grepping for the
message. If you split right before or after a % format specification,
the effect is zero with regards to grepping.
Except that not all editors are configured to wrap. Mine in particular
isn't - I find it very difficult to read source code when long lines
are wrapped. So the extra characters are simply not displayed - and
there it matters somewhat if this is just the trailing "); that I don't
see, or half of the message.
I'll do things the way I like them, I think it will be more efficient
for everyone than discussing the costs and benefits of split strings
for the rest of the day ;)
--
Jean Delvare
--
