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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D8E0C433FE for ; Fri, 19 Nov 2021 16:35:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 49F3C61B27 for ; Fri, 19 Nov 2021 16:35:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236544AbhKSQiy (ORCPT ); Fri, 19 Nov 2021 11:38:54 -0500 Received: from mga07.intel.com ([134.134.136.100]:56497 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235789AbhKSQix (ORCPT ); Fri, 19 Nov 2021 11:38:53 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10172"; a="297861513" X-IronPort-AV: E=Sophos;i="5.87,248,1631602800"; d="scan'208";a="297861513" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2021 08:35:44 -0800 X-IronPort-AV: E=Sophos;i="5.87,248,1631602800"; d="scan'208";a="737108569" Received: from smile.fi.intel.com ([10.237.72.184]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2021 08:35:35 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1mo6rG-008arp-NU; Fri, 19 Nov 2021 18:35:26 +0200 Date: Fri, 19 Nov 2021 18:35:26 +0200 From: Andy Shevchenko To: "Alejandro Colomar (man-pages)" Cc: 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" , Jonathan Cameron , 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: References: <20211119113644.1600-1-alx.manpages@gmail.com> <434296d3-8fe1-f1d2-ee9d-ea25d6c4e43e@gmail.com> <2d790206-124b-f850-895f-a57a74c55f79@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d790206-124b-f850-895f-a57a74c55f79@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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]: -- With Best Regards, Andy Shevchenko