Re: [GIT PULL] Kbuild updates for v6.16-rc1

[Masahiro Yamada]

On Thu, Jun 12, 2025 at 5:01 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Thu, Jun 12, 2025, at 03:42, Masahiro Yamada wrote:
> > On Wed, Jun 11, 2025 at 11:24 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> >> On Wed, Jun 11, 2025, at 15:32, Masahiro Yamada wrote:
> >> > On Wed, Jun 11, 2025 at 4:55 PM Heiko Carstens <hca@xxxxxxxxxxxxx> wrote:
> >> I think this makes sense in general, but the output here is
> >> excessive if it leads to users no longer wanting to enable W=1.
> >>
> >> There are other warnings that I think should be enabled at the
> >> W=1 level (e.g. -Wformat-security) and eventually by default,
> >> but that are still too noisy at that level.
> >>
> >> My own cutoff would be at a few hundred warnings in allmodconfig
> >> builds if there is an effort to reduce it further, but it seems
> >> that this one is still at a few thousand, which does not seem ok.
> >
> > Then, what to do?  Downgrade to W=2?
> >
> > I think nobody cares about W=2 builds,
>
> I think the first step would be mass-cleanup patches to get
> the initial numbers down. A lot of this can be scripted.
>
> > and the problem of all C files including <linux/export.h>
> > would remain forever.
>
> I'm missing a bit of background here, and I don't see this
> explained in the 5b20755b7780 ("init: move THIS_MODULE
> from <linux/export.h> to <linux/init.h>") changelog text
> either

I explained in 5b20755b7780 and also in the comment lines
in scripts/misc-check.


<linux/module.h> is included by modular (i.e. tristate) code,
which is symbol _consumers_.

<linux/export.h> is included by symbol _providers_.

These are independent, or in other words, orthogonal.

Therefore, there is no reason for <linux/module.h>
to include <linux/export.h>.

It is standard to split consumers and providers,
since they are included by different files.
See <linux/clk.h> vs <linux/clk-providers.h> as another example.





> What is the purpose of cleaning the linux/export.h inclusions,
> and what makes this one more important than others?
> I obviously understand that indirect header inclusions are
> a giant mess and that any such cleanup helps, but linux/export.h
> seems particularly small compared to many others. It was
> originally introduced so a lot of files would no longer have
> to pull in linux/module.h if they only care about using
> EXPORT_SYMBOL() and THIS_MODULE, so linux/module.h could
> eventually become private to kernel/module/*.c.

I believe <linux/module.h> will remain, as modules must
define MODULE_LICENSE().


> Is this something you are trying to continue, or are you
> doing something else here?
>
> FWIW, I compared the preprocessed sizes of linux/export.h
> (~2000) and linux/module.h (~120,000), and it seems that almost
> none of those are needed by most of the files including
> linux/module.h. The one part that is commonly required is
> MODULE_{INFO,AUTHOR,LICENSE,DESCRIPTION}, so maybe there would
> be a chance to clean this up at the same time if you are
> planning some large-scale reshuffling of #include statements
> around export.h.
>
>      Arnd

Split <linux/module.h> into public and private is good,
but it is beyond the scope of this work.

Regardless of the file size, if a file does not need to
include <linux/export.h>, the open syscall can be avoided.
80 % of *.c files do not need to include it.



-- 
Best Regards
Masahiro Yamada