Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E69BBC433F5 for ; Mon, 22 Nov 2021 12:36:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239586AbhKVMjy (ORCPT ); Mon, 22 Nov 2021 07:39:54 -0500 Received: from frasgout.his.huawei.com ([185.176.79.56]:4124 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236395AbhKVMjn (ORCPT ); Mon, 22 Nov 2021 07:39:43 -0500 Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HyRZy2XJ5z67Yqx; Mon, 22 Nov 2021 20:36:10 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 22 Nov 2021 13:36:34 +0100 Received: from localhost (10.202.226.41) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 22 Nov 2021 12:36:33 +0000 Date: Mon, 22 Nov 2021 12:36:32 +0000 From: Jonathan Cameron To: Andy Shevchenko CC: "Alejandro Colomar (man-pages)" , Arnd Bergmann , LKML , Ajit Khaparde , Andrew Morton , Bjorn Andersson , Borislav Petkov , Corey Minyard , Chris Mason , "Christian Brauner" , David Sterba , Jani Nikula , Jason Wang , Jitendra Bhivare , John Hubbard , "John S . Gruber" , "Joonas Lahtinen" , Josef Bacik , Kees Cook , Ketan Mukadam , Len Brown , "Michael S. Tsirkin" , Miguel Ojeda , Mike Rapoport , Nick Desaulniers , "Rafael J. Wysocki" , Rasmus Villemoes , Rodrigo Vivi , Russell King , Somnath Kotur , Sriharsha Basavapatna , Subbu Seetharaman , Intel Graphics , ACPI Devel Maling List , Linux ARM , linux-btrfs , linux-scsi , Networking , "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" Subject: Re: [PATCH 00/17] Add memberof(), split some headers, and slightly simplify code Message-ID: <20211122123632.00004b22@Huawei.com> In-Reply-To: References: <20211119113644.1600-1-alx.manpages@gmail.com> <434296d3-8fe1-f1d2-ee9d-ea25d6c4e43e@gmail.com> <2d790206-124b-f850-895f-a57a74c55f79@gmail.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.226.41] X-ClientProxiedBy: lhreml737-chm.china.huawei.com (10.201.108.187) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 19 Nov 2021 18:35:26 +0200 Andy Shevchenko wrote: > On Fri, Nov 19, 2021 at 05:22:48PM +0100, Alejandro Colomar (man-pages) wrote: > > > > > > On 11/19/21 17:18, Arnd Bergmann wrote: > > > On Fri, Nov 19, 2021 at 5:10 PM Andy Shevchenko > > > wrote: > > >> On Fri, Nov 19, 2021 at 04:57:46PM +0100, Arnd Bergmann wrote: > > > > > >>> The main problem with this approach is that as soon as you start > > >>> actually reducing the unneeded indirect includes, you end up with > > >>> countless .c files that no longer build because they are missing a > > >>> direct include for something that was always included somewhere > > >>> deep underneath, so I needed a second set of scripts to add > > >>> direct includes to every .c file. > > >> > > >> Can't it be done with cocci support? > > > > > > There are many ways of doing it, but they all tend to suffer from the > > > problem of identifying which headers are actually needed based on > > > the contents of a file, and also figuring out where to put the extra > > > #include if there are complex #ifdefs. > > > > > > For reference, see below for the naive pattern matching I tried. > > > This is obviously incomplete and partially wrong. > > > > FYI, if you may not know the tool, > > theres include-what-you-use(1) (a.k.a. iwyu(1))[1], > > although it is still not mature, > > and I'm helping improve it a bit. > > Yes, I know the tool, but it produces insanity. Jonathan (maintainer > of IIO subsystem) actually found it useful after manual work applied. > Perhaps you can chat with him about usage of it in the Linux kernel. IIO drivers use a fairly limited subset of headers, so it wasn't implausible to produce a mapping file to get to fairly sane results. https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=iio-iwyu-cleanups&id=8bc7ff8d5385e89a5199e792fda18dbf2ca8f2e5 If we did head towards a general mapping file that 'more or less made sense' then maybe this tool can be fairly useful kernel wide. Typical patch that results in clean checks with that mapping file is: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=iio-iwyu-cleanups&id=0eff2dd097add84c464710003c3bc9929f646427 There are always going to be questions of how many of the really low level direct includes make sense though which was the stumbling block. It is nice to get rid of the pointless includes though for things that due to refactors etc are no longer used in a file, or were cut and paste from another driver. I've paused efforts on this front for now given series like this one can have significant impact and it seems to be an active area at the moment. Might revisit later this cycle. Jonathan > > > If I understood better the kernel Makefiles, > > I'd try it. > > > > You can try it yourselves. > > I still can't use it for my own code, > > since it has a lot of false positives. > > > [1]: >