Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

[Alexey Dobriyan <adobriyan@gmail.com>]

On Mon, Sep 06, 2021 at 08:54:13AM +0200, Florian Weimer wrote:
> * Linus Torvalds:
> 
> > On Sat, Sep 4, 2021 at 8:19 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> In any case, it would be nice to know what the real motivation is.
> >
> > I don't know about the original motivation, but the reason I like that
> > patch after-the-fact is that I've actually been in situations where I
> > test out self-built compilers without installing them.
> 
> Does this really simplify matters?  Why wouldn't the gcc compiler driver
> find cc1, but not be able to pass the right path options, so that the
> include/ subdirectory can be located as well?
> 
> > Then it's convenient to have a completely standalone kernel tree.
> 
> The final patch in the series is here:
> 
>   isystem: delete global -isystem compile option
>   <https://lore.kernel.org/linux-kernel/YQhY40teUJcTc5H4@localhost.localdomain/>
> 
> It's still not self-contained.

What do you mean?

Mainline has 1/3 and 2/3 now:

	c0891ac15f0428ffa81b2e818d416bdf3cb74ab6 isystem: ship and use stdarg.h
	39f75da7bcc829ddc4d40bb60d0e95520de7898b isystem: trim/fixup stdarg.h and other headers

3/3 is stuck in -next:

	https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=for-next

I'm not sure why. If the patch is bad it should be dropped from -next
as well. If it is good, it should be in mainline, otherwise more
compile time failures will happen.

>  And it seems that there has been quite a
> bit of fallout from the removal of <stddef.h>.
> 
> > Nobody cares about things like <stdatomic.h> They are completely
> > irrelevant for the kernel, exactly because we've always just done our
> > own, or used __builtin_xyz() for things.
> 
> Apparently, some people care enough about <stdatomic.h> to prevent its
> use.  I still have not seen an explanation.  Maybe it's because we
> haven't Cc:ed the patch author so far (oops).
> 
> Alexey, why are <stdatomic.h> and <float.h> so special that you called
> them out in your patch?
> 
> If it's about unintended use of libatomic, then maybe we should work on
> a proper compiler option that also works for __atomic builtins and the
> _Atomic keyword.

stdatomic.h isn't magic really. I looked at what gcc here ships and
found these headers. Clearly kernel doesn't want alien stdatomic.h
injections because kernel has their own atomic model.

Kernel doesn't want any floating point shenanigans either.
I think I saw 1 instance of "float" usage but it was harmless (some
macro which is converted to an integer at compile time)

Kernel doesn't want any future stuff either unless vetted.

I can only repeat what I wrote when sending previous versions:
kernel clearly isolates itself from userspace, -isystem merely step in
the same direction.

Other direction (kernel uses what standard says should be available) is
fine in principle but it is not my decision to make. And it is more
painful, just try to s/u8/uint8_t/g and see what happens. Or, worse,

	#define and &&
	#define or  ||

Just try it.

I also want to note that kernel version are slightly incompatible,
but better!

* bool should be a macro (module_param(bool) breaks) but it better
  for everyone if it is a typedef,

* true and false should be macros, but they look better in preprocessor
  output if they are enum.

* SHRT_MAX is of type "int",
  which is silly because typeof(short) != typeof(SHRT_MAX)

Practice of many trivial headers is in general worse for compile times,
because open/read/parse/close can't be faster than global -Dnoreturn=_Noreturn