Received: by 10.223.176.46 with SMTP id f43csp811656wra; Fri, 19 Jan 2018 02:17:41 -0800 (PST) X-Google-Smtp-Source: ACJfBosC/bpQoOTjwgWkP0Yl/Y8HYJqrkrlkE++PKGVhf2M6sQMh1lWL2F50CfMIvYTLNcQjwaKy X-Received: by 10.98.232.14 with SMTP id c14mr5448472pfi.215.1516357061501; Fri, 19 Jan 2018 02:17:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516357061; cv=none; d=google.com; s=arc-20160816; b=Qe95U9gFcGifOaNqNabG7ikJuwK0uWo/i98vhV3oxspsyAI03obhmLEa6LyzdhfQSm YQ8YdU2poihV79snyKCIsohAJe1fpj5ADVb0YlXzahHBa6uN3tWTJamUbHhru8lvTdGn T/wrvyrSbYJA0V9Lb+mngbNnAvNh3YPfgQ4CCmifqgrAAv0Vt04jGFxkP0gouGhLVBtS 1QTBE4I5aQE1qaOWWdId0SsiKkVvU6kpasCBIqvv4yybk1hZP6V5TZgfyY9gevXneZUZ 8FMHSKu48Hk27RCCHRAR64+TlD12N02sooXpcjhQoehF+SIcTSIyixPQzDZc9wjHoonR oPqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=LIFdiSiWVs3VhNvSVbRUqpQzWMdfSdqOLvUzMbNjXs8=; b=KxZmMprzQfLEzQah+EtXGW4kiHwQ0varORC5f30j68JSVHCOLOQWhNFQubTJprEjuh JLeLO0H/RJ8UmwuI5JmXUgwPQUpbA6mgJ9QC2pAMMxpDQjb0l89gHj1JAyf4I9d6XQMU GSiMhf4uqRb6ku/62ctciGv4uc3dsCvgcVjjRNKVamysLc4FUFRv5fvA8/SwE5w8awaX uN9mKHraoiXyTXLOoxznxxCxLEzZQEs0Y/PbCECCGJ/Jw+BKvelk8BcgON4Z+3aChng0 lGSxURsxm3AkadvNx7w97pP6LSXMdO41+HKWLhohkitG4komAEPvt3Mv4ZGd8DnhCrFF 4ztw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=OoOmsJEN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t83si8986769pfi.53.2018.01.19.02.17.27; Fri, 19 Jan 2018 02:17:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=OoOmsJEN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755400AbeASKQ6 (ORCPT + 99 others); Fri, 19 Jan 2018 05:16:58 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:60142 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755020AbeASKQw (ORCPT ); Fri, 19 Jan 2018 05:16:52 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0JADY6m011032; Fri, 19 Jan 2018 10:15:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=LIFdiSiWVs3VhNvSVbRUqpQzWMdfSdqOLvUzMbNjXs8=; b=OoOmsJEN0AsSvMm/f5pH9CrWBj4tJA+eOmc5fKBXaL4jp2KMVYS45OnPAydgHx3LH8pt NbVNfOwpi4A+m5qb8OSkAZGKUpk8dKsDX8twyk7qKx1I8ehMojGGx98r1DAD9ihhD4Kn cQYuVq0H3FBpw1/j8gi9XLpDz4Ffb+obVWZ1sV/LYfPXk3mJUeYXSwd8BheqejSo65xH U1YK1l9y3KlBrAgt8HBpYvw4ji6WNXUVHdruEy8OaOUOs1FpR7A55Lq3ubnbpctc9vY8 jjs8iTkfeEIpkXK65HGq++iyRKQw6Jt7Xnsm4OY5zvmofgX6+a9w0aR7f2qS8yQeoY+4 ag== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2fkcxc0fvm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 19 Jan 2018 10:15:32 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0JAFRUF014009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Jan 2018 10:15:27 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0JAFNUu001779; Fri, 19 Jan 2018 10:15:24 GMT Received: from abi.no.oracle.com (/10.172.144.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Jan 2018 02:15:23 -0800 From: Knut Omang To: linux-kernel@vger.kernel.org Cc: Knut Omang , Mauro Carvalho Chehab , Shuah Khan , Nicolas Palix , Masahiro Yamada , linux-kbuild@vger.kernel.org, John Haxby , linux-doc@vger.kernel.org, Jonathan Corbet , Gilles Muller , Tom Saeger , Michal Marek , =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= , "Paul E. McKenney" , Julia Lawall , =?UTF-8?q?H=C3=A5kon=20Bugge?= , =?UTF-8?q?=C3=85smund=20=C3=98stvold?= , Matthew Wilcox , "Levin, Alexander (Sasha Levin)" , cocci@systeme.lip6.fr, Andrew Morton Subject: [PATCH v4 0/1] Support for generalized use of make C={1,2} via a wrapper program Date: Fri, 19 Jan 2018 11:14:54 +0100 Message-Id: X-Mailer: git-send-email 2.13.6 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8778 signatures=668654 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801190130 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch implements features to make it easier to run checkers on the entire kernel as part of automatic and developer testing. This is done by replacing the sparse specific setup for the C={1,2} variable in the makefiles with setup for running scripts/runchecks, a new program that can run any number of different "checkers". The behaviour of runchecks is defined by simple conceptually global configuration in scripts/runchecks.cfg which can be extended by local configuration applying to individual files, directories or subtrees in the source. The runchecks.cfg files are parsed according to this minimal language: # comments # "Global configuration in scripts/runchecks.cfg: checker typedef NAME regex run except checkpatch_type [files ...] pervasive checkpatch_type1 [checkpatch_type2 ...] With "make C=2" runchecks first parse the file scripts/runchecks.cfg, then look for a file named 'runchecks.cfg' in the same directory as the source file. If that file exists, it will be parsed and it's local configuration applied to allow suppression on a per checker, per check and per file basis. If a "local" configuration does not exist, either in the source directory or above, make will simply silently ignore the file. This way the semantics of "no in-tree runchecks.cfg file" is equivalent to a configuration where all checks have been suppressed. The idea is that the community can work to add runchecks.cfg files to directories, serving both as documentation and as a way for subsystem maintainers to enforce policies and individual tastes as well as TODOs and/or priorities, to make it easier for newcomers to contribute in this area. By ignoring directories/subtrees without such files, automation can start right away as it is trivially possible to run errorless with C=2 for the entire kernel. For the checker maintainers this should be a benefit as well: new or improved checks would generate new errors/warnings. With automatic testing for the checkers, these new checks would generate error reports and cause builds to fail. Adding the new check a 'pervasive' option at the top level or even for specific files, marked with a "new check - please consider fixing" comment or similar would make those builds pass while documenting and making the new check more visible. The patch includes documentation with some more details. This patch has evolved from an earlier shell script implementation I made as only a wrapper script around checkpatch. That version have been used for a number of years on a driver project I worked on where we had automatic checkin regression testing. I extended that to also run checkpatch to avoid having to clean up frequent unintended whitespace changes and style violations from others... I have also tested this on some directories I am familiar with. The result of that work is available in two patch sets of 10 and 11 patches. I will post these fixes as separate patch sets later. Version 3-1 of this set and related discussion can be found here: v3: https://lkml.org/lkml/2018/1/4/359 v2: https://lkml.org/lkml/2017/12/16/343 v1: https://lkml.org/lkml/2017/11/16/458 Changes from v3: ----------------- * Used argparse for argument parsing * Update 'make help' to reflect changes * Added support for smatch (see https://blogs.oracle.com/linuxkernel/smatch-static-analysis-tool-overview,-by-dan-carpenter) * Removed superfluous license statements * Fixed a broken sys.stderr.write() statement in runchecks, as well as a few minor error handling improvements. * Also fixed some python style issues reported by pep8/flake8 Changes from v2: ----------------- * Squashed patches #1 and #2 from v2. Fixed a few spelling errors + some suggested text improvements in the docs. * Shelved patch #3 as it's usefulness is not clear * Removed patch #4-#5 as they were included here as examples for discussion * rebased to v4.15-rc6 Changes from v1: ----------------- Based on feedback, the implementation is completely rewritten and extended. Instead of patches to checkpatch, and a sole checkpatch focus, it is now a generic solution implemented in python, for any type of checkers, extendable through some basic generic functionality, and for special needs by subclassing the Checker class in the implementation. This implementation fully supports checkpatch, sparse, smatch, and checkdoc == kernel-doc -none, and also has been tested with coccicheck. To facilitate the same mechanism of using check types to filter what checks to be suppressed, I introduced the concept of "typedefs" which allows runchecks to effectively augment the check type space of the checker in cases where types either are not available at all (checkdoc) or where only a few can be filtered out (sparse) With this in place it also became almost trivial to make the look and feel similar for sparse, smatch and checkdoc as for checkpatch, with some optional color support too, to make fixing issues in the code, the goal of this whole exercise, much more pleasant IMHO :-) Thanks, Knut Knut Omang (1): runchecks: Generalize make C={1,2} to support multiple checkers Documentation/dev-tools/coccinelle.rst | 12 +- Documentation/dev-tools/index.rst | 1 +- Documentation/dev-tools/runchecks.rst | 215 +++++++- Documentation/dev-tools/sparse.rst | 30 +- Documentation/kbuild/kbuild.txt | 9 +- Makefile | 31 +- scripts/Makefile.build | 4 +- scripts/runchecks | 809 ++++++++++++++++++++++++++- scripts/runchecks.cfg | 166 +++++- 9 files changed, 1255 insertions(+), 22 deletions(-) create mode 100644 Documentation/dev-tools/runchecks.rst create mode 100755 scripts/runchecks create mode 100644 scripts/runchecks.cfg base-commit: 30a7acd573899fd8b8ac39236eff6468b195ac7d -- git-series 0.9.1