From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965959AbdKPRoT convert rfc822-to-8bit (ORCPT ); Thu, 16 Nov 2017 12:44:19 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:48861 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965836AbdKPRnk (ORCPT ); Thu, 16 Nov 2017 12:43:40 -0500 Message-ID: <1510854208.3063.33.camel@oracle.com> Subject: Re: [PATCH 1/7] checkpatch: Implement new --ignore-cfg parameter From: Knut Omang To: Joe Perches , linux-kernel@vger.kernel.org Cc: Andy Whitcroft , Andrew Morton Date: Thu, 16 Nov 2017 18:43:28 +0100 In-Reply-To: <1510852186.31559.37.camel@perches.com> References: <280c16fb1b8a645f0c62cea03f440fd0661af898.1510840787.git-series.knut.omang@oracle.com> <1510852186.31559.37.camel@perches.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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