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

[Segher Boessenkool]

On Sat, Sep 04, 2021 at 05:19:21PM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
> 
> > Let me quote the original mail (I had to dig it out of the archives as
> > well, no nice threading, too lazy, sorry):
> 
> It still doesn't say why.  I did see a reference to fleeting reference
> to <stdatomic.h> and <float.h>.

Yeah...  I dug out the actual patch from linux-kbuild:

https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild-v5.15&id=c0891ac15f0428ffa81b2e818d416bdf3cb74ab6

The reasoning in there is completely wrong.  <stdarg.h> is not a
"userspace header".  Instead, it is a standard header, required for some
functionality in C.

It also says
"GPL 2 version of <stdarg.h> can be extracted from
http://archive.debian.org/debian/pool/main/g/gcc-4.2/gcc-4.2_4.2.4.orig.tar.gz";
which seems to suggest you cannot use stuff from GPLv3-licensed GCC.
This is just wrong.  The header in question says

"""
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
"""

And <https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=COPYING.RUNTIME>
reads in part

"""
 1. Grant of Additional Permission.

  You have permission to propagate a work of Target Code formed by
  combining the Runtime Library with Independent Modules, even if such
  propagation would otherwise violate the terms of GPLv3, provided that
  all Target Code was generated by Eligible Compilation Processes. You
  may then convey such a combination under terms of your choice,
  consistent with the licensing of the Independent Modules.
"""

which says that if you compile with GCC, then it is perfectly fine if it
uses the standard C headers, it does not make your work GPL-licenced.

> After all, <stdatomic.h> is exactly like <stdarg.h> in that it's
> possible to use its functionality even without the header file.  The
> __atomic builtins are even documented in the GCC manual (unlike
> <stdatomic.h>), which is why some programmers prefer them over the
> standard interface.  And then there's the _Atomic keyword itself, whose
> use can easily result in calls to libatomic functions, too.  So blocking
> <stdatomic.h> makes little sense to me.
> 
> I don't know enough about softfloat if blocking the inclusion of
> <float.h> is worth it.

Blocking the use of <float.h> is pretty useless: it is possible to do
millions of things in the kernel source that are frowned upon, or
actively bad, or anything in between or more extreme.  That is what code
review is for.  If it would be a common mistake (it is not afaik) you
can warn for it from checkpatch.pl or something.

The patch is just re-implementing part of the standard GCC <stdarg.h>,
so that it will only work with recent GCC (and maybe clang as well if it
implements the GCC internal interfaces correctly (i.e. compatibly) here,
and the same for other compilers).  Almost all of the <stdarg.h> GCC
itself uses is the same, but it also is compatible to the various C
standards if this header is included indirectly.  That is all just some
ifdeffery anyway, so doesn't influence compilation times noticeably, and
all that.

   - * -

So as far as I can see the motivation behind the patch is a) a
misunderstanding of what standard C headers are, are for, etc.; and b)
a misunderstanding of the GPL and the GCC runtime exception to it.  The
patch makes things worse than they were.  If on the contrary Linux would
use *more* standard compiler headers, say <stddef.h>, then insidious
bugs like that fixed by c46bbf5d2def would be prevented.


Segher