Received-SPF: pass (google.com: domain of linux-kernel+bounces-17963-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 5 Jan 2024 15:45:56 +0100
From: Borislav Petkov <bp@alien8.de>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tanzir Hasan <tanzirh@google.com>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org,
	Kees Cook <keescook@chromium.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andy Shevchenko <andy@kernel.org>
Subject: Re: [PATCH] x86/vdso: shrink vdso/extable.i via IWYU
Message-ID: <20240105144556.GBZZgWJOjq6Ekmps6Z@fat_crate.local>
References: <20231228-extable-v1-1-32a18c66b440@google.com>
 <20231228212511.GCZY3nt3gKI+aDvSF1@fat_crate.local>
 <CAE-cH4rEWU-+ovwo8_-i3b2F8pK17kORJ3gV5tnjnUpRJA+B0Q@mail.gmail.com>
 <20231229093942.GBZY6T3knaGKpeRA9a@fat_crate.local>
 <CAKwvOd=aSQq3mcxGe-csNcygFWCbq03CPYFyc5DhjyvL_qYPAQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAKwvOd=aSQq3mcxGe-csNcygFWCbq03CPYFyc5DhjyvL_qYPAQ@mail.gmail.com>

On Wed, Jan 03, 2024 at 11:36:35AM -0800, Nick Desaulniers wrote:
> By being more precise in what's necessary via making more specific use
> of includes (making "indirect" includes into "direct" includes) in the
> .c files, it will allow us to more easily refactor the header files
> themselves.

I know, but you have to realize that header files are not a static thing
- we do "refactor" them all the time. So it's not like we'll refactor
them and they'll be done. No, we'll refactor them again later.

> And yes, these inclusion lists will change over time.  As you say
> below, they can be cleaned up again every couple of releases.  Though
> right now most files have never been cleaned up at all.

Yap, the need for some tool or facility to keep include files proper and
optimal is indisputable. There's a reason it is called the "Include
Hell".

> Over time, they will add up. But not if we reject the patches as
> unnecessary churn.

There's the other side of that coin: if we keep applying those, it'll
turn into a never-ending stream of silly fixes. Like spellchecking and
whitespace cleanups. And maintainers will start ignoring them.

> Maybe the overall numbers are interesting, but landing one patch that
> updates numerous .c files' inclusion lists seems error prone.  I
> suspect it's more likely that a more incremental approach of smaller
> patches allows progress if there are any issues; a build
> failure/mistake doesn't block the whole thing from landing.
> 
> Overall numbers can also be collected after the fact.

You could do a single patch *set* and say, before and after, we get
these improvements. And the whole set goes in in one fell swoop.

> > And then do it
> > again in a couple of releases, when it becomes necessary again.
> 
> That's the use case I had in mind.  Though I suspect the initial run
> of this tooling will result in the most changes, as some files in tree
> are hardly touched between releases. For those, I don't expect any
> automated tooling to be churning those files after the initial
> cleaning.

That's why I said "when it becomes necessary". :)

> Yeah, the idea is that the tooling results in repeatable processes by
> others.  One could imagine build bots running this, or integrating it
> into checkpatch, or git presubmit hooks, or w/e.

Yap, that would be best. Because it'll stop from the whole include hell
from even ensuing in the first place.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette