On Mon, Aug 02, 2021 at 11:47:47AM -0500, Segher Boessenkool wrote:

On Mon, Aug 02, 2021 at 09:42:45AM +0300, Alexey Dobriyan wrote:

quoted

On Sun, Aug 01, 2021 at 04:32:47PM -0500, Segher Boessenkool wrote:

quoted

On Sun, Aug 01, 2021 at 11:13:36PM +0300, Alexey Dobriyan wrote:

quoted

In theory, it enables "leakage" of userspace headers into kernel which
may present licensing problem.

quoted

-NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
+NOSTDINC_FLAGS += -nostdinc

This is removing the compiler's own include files.  These are required
for all kinds of basic features, and required to be compliant to the C
standard at all.

No they are not required.

This is false, they *are* required, whenever you want to use these
features.  If you do not include the required headers you get undefined
behaviour.

quoted

Kernel uses its own bool, uintptr_t and
static_assert, memset(), CHAR_BIT.

Yes, and it occasionally gets it wrong.  Great fun.  See c46bbf5d2def
for the latest episode in this saga.  (Yes I know this is uapi so maybe
not the best example here, but it isn't like the kernel gets such things
wrong so often these days ;-) )

The kernel *cannot* make up its own types for this.  It has to use the
types it is required to use (by C, by the ABIs, etc.)  So why
reimplement this?

Yes, it can. gcc headers have stuff like this:

	#define __PTRDIFF_TYPE__ long int
	#define __SIZE_TYPE__ long unsigned int

If gcc can defined standard types, kernel can too.

quoted

noreturn, alignas newest C standard
are next.

What is wrong with <stdalign.h> and <stdnoreturn.h>?

These two are actually quite nice.

Have you seen <stddef.h>? Loads of macrology crap.
Kernel can ship nicer one.

quoted

This version changelog didn't mention but kernel would use
-ffreestanding too if not other problems with the flag.

It is still true for freestanding C implementations, you just get a
severely reduced standard library,

quoted

quoted

These are not "userspace headers", that is what
-nostdinc takes care of already.

They are userspace headers in the sense they are external to the project
just like userspace programs are external to the kernel.

So you are going to rewrite all of the rest of GCC inside the kernel
project as well?

What an argument. "the rest of GCC" is already there except for stdarg.h.

quoted

quoted

In the case of GCC all these headers are GPL-with-runtime-exception, so
claiming this can cause licensing problems is fearmongering.

I agree licensing problem doesn't really exist.
It would take gcc drop-in replacement with authors insane enough to not
license standard headers properly.

There does still not exist a drop-in replacement for GCC, not if you
look closely and/or rely on details (like the kernel does).  Some of the
differences are hidden by "linux/compiler-*.h", but hardly all.

quoted

quoted

I strongly advise against doing this.

Kernel chose to be self-contained.

That is largely historical, imo.  Nowadays this is less necessary.

I kind of agree as in kernel should use int8_t and stuff because they
are standard.

Also, -isystem removal disables <float.h> and <stdatomic.h> which is
desireable.

Also, the kernel chose to *do* use the compiler include files.  It is
you who wants to abolish that here.

quoted

-isystem removal makes sense then.

-nostdinc -isystem $(shell $(CC) -print-file-name=include)  makes sense
for that: you do indeed not want the userspace headers.  Maiming the
compiler (by removing some of its functional parts, namely, its generic
headers) does not make sense.

quoted

It will be used for intrinsics where necessary.

Like, everywhere.

No, where necessary. Patch demostrates there are only a few places which
want -isystem back.