linux-kernel - Re: [PATCH 1/7] checkpatch: Implement new --ignore-cfg parameter

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]

Date:   Thu, 16 Nov 2017 18:43:28 +0100
From:   Knut Omang <knut.omang@...cle.com>
To:     Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org
Cc:     Andy Whitcroft <apw@...onical.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/7] checkpatch: Implement new --ignore-cfg parameter

On Thu, 2017-11-16 at 09:09 -0800, Joe Perches wrote:
> (adding Andrew Morton)
> 
> On Thu, 2017-11-16 at 18:01 +0100, Knut Omang wrote:
> > This parameter is intended to be used in a subsequent commit to kbuild to allow
> > a convenient way to run checkpatch from make.
> 
> _why_ is this useful?

The cover letter and the following documentation patch hopefully makes it 
clearer. 

I realize the cc: list on the cover letter was a little too narrow, sorry about that!

> > By accepting comments and multiple lines of commands, the idea is that the
> > maintainer or someone else with good knowledge of the code can maintain a file
> > per directory and group the different commands into commented sections that can
> > serve both as documentation of the current checkpatch status, a way to define
> > the line of tolerance (and gradually tighten it as fixes comes in) and as
> > documentation of TODOs and dont's if there are well justified exceptions.
> 
> checkpatch can be run any time over individual files
> so I don't find this compelling.

The problem with that in general is the noise level.
What this patch set gives is in short:

* a way to filter out the noise to focus on one type of error at the time
* the means to automate prevention of reoccurrence of some types of checkpatch 
  errors that have been removed from a file, even when that file has
  100s of checkpatch issues of other types.

> Does anyone else?

I did subject the set to a couple of internal reviews with positive feedback. 
We have also had automated checkin regression testing going with 
a similar system for some time.  I was just going to improve upon that system
when I realized that we should really make it available for the broader community.

I hope this helps,

thanks,
Knut