From: "ext Riku Voipio" <riku.voipio@xxxxxx>
Subject: Re: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux-omap
Date: Mon, 18 Aug 2008 12:13:05 +0300
> 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.
Yes, this is also the another point to be fixed.
Homebrewed APIs(sync, list, clk) in bridge should be replaced by
kernel APIs. Some of them are enhaced with some debug trace features,
but if these features are really necessary, they should be
implmemented in Linux kernel APIs or shold be in the more upper layer
of bridge to check.
Probably you can also find other trivial things in:
Documentation/CodingStyle
Documentation/SubmitChecklist
Documentation/SubmittingPatches
Hiroshi DOYU
--
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
