On Fri, Aug 15, 2008 at 03:16:29PM -0500, Woodruff, Richard wrote: > Checkpatch.pl is just a guide. Completely changing code for the tool isn't probably a good idea. It might even get you severally flamed on LKML :) The recent threads are informative (ok to read, bad to be in). > Incidentally, when I asked the person working these changes, they had reported 0 functional errors had been fixed by the checkpatch changes. A lot of the noise was typedef reduction. I don't think completly fair complaint. checkpatch.pl is only meant to check that patches comply to the kernel Coding style. For a huge project such as Linux kernel, all code must be written in uniform style. DSP bridge has probably been written following TI's internal codingstyle documents, and as a first step it needs to be converted to follow the Linux codingstyle. checkpatch not a static analysing tool, which would be neccessary for uncovering functional errors. For that we have sparse, and mainline kernel gets regularry checked with the coverity scanner. Focusing on checkpatch errors is a bit deceptive. It is perfectly possible to be "checkpatch clean" yet the code has lots of issues left. For example checkpatch cannot tell that CSL_Strlen() can be replaced with strlen() from kernel. -- "rm -rf" only sounds scary if you don't have backups -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
