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

On Mon, Sep 06, 2021 at 08:27:25PM +0200, Florian Weimer wrote:

* Linus Torvalds:

quoted

We use the compiler intrinsics without the C library header files for
everything else, so doing so for <stdarg.h> seems to actually be a
clarification and improvement.

This is an exaggeration.  On several architectures, the kernel cannot
use the vector built-ins directly.  Some of the implementing headers are
very special and intertwined with the compiler.  <stdarg.h> is currently
not such a case, but it's just not technically not feasible to avoid
dependencies on all compiler headers.  I think this considerably weakens
the case against <stdarg.h> because the compiler version is so obviously
harmless.

Exactly Florian.  Thank you for so clearly making the point.

What the kernel is doing here is imposing an unnecesary constraint on
compiler development.  Basically, you are telling compiler writers that
implementing features with the help of header files is a bad idea
because it makes it more difficult to use them from the kernel.  (See
the proposed exceptions for vector code.)

Either it will constrain the compiler development, or perhaps more
likely, building the kernel will break in ways that the kernel people
will blame the compiler developers for.

The compiler headers (standard or arch-specific, same reason here) are
there because it decouples the user (that doesn't mean "userland", it
means the kernel here) from the builtins.  Decoupling has many
advantages.  The most obvious in general is you can use nicer names in
a header file, names that can step on the user's toes (like "bool" vs.
"_Bool", which is essentially all that <stdbool.h> does).  But another
huge advantage of decoupling is it allows the compiler more freedom in
bugfixing (or any other maintenance / new development).

It is low probability that there are bugs in the compiler's standard
headers, and it's not likely the kernel's ad-hoc imitation of it has
bugs, this is all so small after all (but have I mentioned the
c46bbf5d2def commit?)

So there is no big pressure for changing anything here.  But OTOH it
clearly is not a good idea to remove the existing uses of standard
headers.  No upsides, various downsides, and some of those can be very
costly.


Segher