linux-kernel - Re: Expanding checkpatch for non-linux (specifically U-Boot) use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DB51333.7060809@gmail.com>
Date:	Mon, 25 Apr 2011 16:22:43 +1000
From:	Graeme Russ <graeme.russ@...il.com>
To:	Joe Perches <joe@...ches.com>
CC:	Andy Whitcroft <apw@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	U-Boot Users <u-boot@...ts.denx.de>
Subject: Re: Expanding checkpatch for non-linux (specifically U-Boot) use

On 25/04/11 16:02, Joe Perches wrote:
> On Mon, 2011-04-25 at 15:36 +1000, Graeme Russ wrote:
>> There has been a bit of discussion lately on the U-Boot mailing list
>> regarding the use of checkpatch for U-Boot patches (see
>> http://lists.denx.de/pipermail/u-boot/2011-April/090954.html)
>>
>> U-Boot uses the Linux coding style and checkpatch is therefore a very good
>> tool for us to use to check style compliance. However, checkpatch has a few
>> Linux specific checks which throw up false warnings for U-Boot patches like:
>>
>> WARNING: consider using kstrto* in preference to simple_strto*
>> WARNING: Use #include <linux/$file> instead of <asm/$file>
>>
>> Also, checkpatch seems to be checking not only patched lines, but context
>> lines as well. There is a policy for U-Boot patches to not intermix
>> whitespace / code cleanup changes and functional changes in in the same
>> patch. So to achieve zero warnings and errors, the submitter is forced to
>> create an additional code-cleanup patch in addition to the functionality
>> patch. The code cleanup can end up being significantly larger than the
>> functionality change which discourages casual submitters.
>>
>> So I have a pretty simple question to ask of LKML - Will checkpatch patches
>> to create a 'U-Boot' command-line option to explicitly filter out Linux
>> specific warnings and errors ever be accepted into checkpatch, or will we
>> be required to create and maintain a U-Boot specific version?
>>
>> P.S. If you could please keep the U-Boot mailing list Cc'd, that would be
>> appreciated
> 
> Hi Graeme.
> 
> Perhaps some sort of .checkpatch.conf file
> could be introduced which could be linked to
> specific types of errors/warnings/checks
> that should be reported or ignored.
> 
> checkpatch has central routines to emit messages.
> 
> sub ERROR {
> 	if (report("ERROR: $_[0]\n")) {
> 		our $clean = 0;
> 		our $cnt_error++;
> 	}
> }
> sub WARN {
> 	if (report("WARNING: $_[0]\n")) {
> 		our $clean = 0;
> 		our $cnt_warn++;
> 	}
> }
> sub CHK {
> 	if ($check && report("CHECK: $_[0]\n")) {
> 		our $clean = 0;
> 		our $cnt_chk++;
> 	}
> }
> 
> For instance, warnings could be changed to include
> a new unique identifier for each message.
> 
> from
> 	WARN("Signed-off-by: is the preferred form\n" .
> 					$herecurr);
> to
> 	WARN($WARN_SIGN_OFF,
> 	     "Signed-off-by: is the preferred form\n" .
> 					$herecurr);
> 
> and the ERROR/WARN/CHK routines could be extended to use
> entries in the .conf file to enable/disable each message.
> 
> uboot could then use an appropriate .conf file.
> 

I like this - And checkpatch.pl could set the default options for 'Linux
flavour' so Linux would not need a .conf file :)

BUT - The question still remains - Will patches for obviously non-Linux
related 'features' of checkpatch be welcomed and incorporated into checkpatch?

Regards,

Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/