Re: [PATCH] x86/vdso: shrink vdso/extable.i via IWYU

[Borislav Petkov]

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