On Sat, 19 Oct 2019 10:33:00 +1300, Paulo Almeida said:
1 - This specific code block has been around for quite some time and many additions using the correct printk(KERN_* were made after it was written. Does that mean that this code block is an exception and should be left as-is for some technical reason? Or, people have somehow forgotten about it and I finally found something to do? :)
There's a meta-consideration or two here to think about. First, many maintainers are not thrilled with trivial patches to code, especially checkpatch cleanups. That's because those patches fall into two major categories: The patch is against code that's debugged and rock solid stable. Most of do_mounts.c is close to a decade old, and it's only being changed when it's needed to add an actual feature (such as mounting by partition label in 2018 or mounting a CIFS filesystem this year). And we *have* had what looked like "trivial checkpatch cleanup" patches that were buggy and broke stuff. The other category is "patches against code that's being worked on". If it's something that somebody else is working on, it can cause merge conflicts, which make maintainers grumpy. So the maintainer only wants to see those cleanups if they're by the person who's working on the code, at the front of the patch series, so that (presumably) they don't have merge commits and they've gotten some compile and run testing. The other big consideration is git. Yes, git knows where and when every single line of code came from. That doesn't mean it's always easy to get it to cough up information. For example: 'git blame init/do_mounts.c'. That tells you where each line came from. Now... imagine a commit that did a spaces-to-tabs cleanup on lines 249 to 257. git blame' now lists the cleanup commit, not the 6 commits that added the original code. Exercise for the reader: Determine the easiest way to get 'git blame' to show you the original 6 commits rather than the cleanup.