@@ -979,7 +979,7 @@ KBUILD_CFLAGS += -falign-functions=64endif# arch Makefile may override CC so keep this after arch Makefile is included-NOSTDINC_FLAGS+=-nostdinc-isystem$(shell$(CC)-print-file-name=include)+NOSTDINC_FLAGS+=-nostdinc# warn about C99 declaration after statementKBUILD_CFLAGS+=-Wdeclaration-after-statement
@@ -14,6 +14,8 @@ hostprogs += mktablesifeq ($(CONFIG_ALTIVEC),y)altivec_flags:=-maltivec$(callcc-option,-mabi=altivec)+# Enable <altivec.h>+altivec_flags+=-isystem$(shell$(CC)-print-file-name=include)ifdef CONFIG_CC_IS_CLANG# clang ppc port does not yet support -maltivec when -msoft-float is
@@ -34,6 +36,8 @@ endif# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)ifeq ($(CONFIG_KERNEL_MODE_NEON),y)NEON_FLAGS:=-ffreestanding+# Enable <arm_neon.h>+NEON_FLAGS+=-isystem$(shell$(CC)-print-file-name=include)ifeq ($(ARCH),arm)NEON_FLAGS+=-march=armv7-a-mfloat-abi=softfp-mfpu=neonendif
--
2.31.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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. These are not "userspace headers", that is what
-nostdinc takes care of already.
In the case of GCC all these headers are GPL-with-runtime-exception, so
claiming this can cause licensing problems is fearmongering.
I strongly advise against doing this.
Segher
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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. Kernel uses its own bool, uintptr_t and
static_assert, memset(), CHAR_BIT. noreturn, alignas newest C standard
are next.
This version changelog didn't mention but kernel would use
-ffreestanding too if not other problems with the flag.
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.
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.
I strongly advise against doing this.
Kernel chose to be self-contained. -isystem removal makes sense then.
It will be used for intrinsics where necessary.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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.
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?
noreturn, alignas newest C standard
are next.
What is wrong with <stdalign.h> and <stdnoreturn.h>?
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
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?
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
I strongly advise against doing this.
Kernel chose to be self-contained.
That is largely historical, imo. Nowadays this is less necessary.
Also, the kernel chose to *do* use the compiler include files. It is
you who wants to abolish that here.
-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.
On Sun, Aug 01, 2021 at 11:13:36PM +0300, Alexey Dobriyan wrote:
In theory, it enables "leakage" of userspace headers into kernel which
may present licensing problem.
In practice, only stdarg.h was used, stdbool.h is trivial and SIMD
intrinsics are contained to a few architectures and aren't global
problem.
In general, kernel is very self contained code and -isystem removal
will further isolate it from Ring Threeland influence.
nds32 keeps -isystem globally due to intrisics used in entrenched header.
-isystem is selectively reenabled for some files.
Not compile tested on hexagon.
With this series on top of v5.14-rc4 and a tangential patch to fix
another issue, ARCH=hexagon defconfig and allmodconfig show no issues.
Tested-by: Nathan Chancellor <redacted> # build (hexagon)
@@ -979,7 +979,7 @@ KBUILD_CFLAGS += -falign-functions=64endif# arch Makefile may override CC so keep this after arch Makefile is included-NOSTDINC_FLAGS+=-nostdinc-isystem$(shell$(CC)-print-file-name=include)+NOSTDINC_FLAGS+=-nostdinc# warn about C99 declaration after statementKBUILD_CFLAGS+=-Wdeclaration-after-statement
@@ -14,6 +14,8 @@ hostprogs += mktablesifeq ($(CONFIG_ALTIVEC),y)altivec_flags:=-maltivec$(callcc-option,-mabi=altivec)+# Enable <altivec.h>+altivec_flags+=-isystem$(shell$(CC)-print-file-name=include)ifdef CONFIG_CC_IS_CLANG# clang ppc port does not yet support -maltivec when -msoft-float is
@@ -34,6 +36,8 @@ endif# ARM/NEON intrinsics in a non C99-compliant environment (such as the kernel)ifeq ($(CONFIG_KERNEL_MODE_NEON),y)NEON_FLAGS:=-ffreestanding+# Enable <arm_neon.h>+NEON_FLAGS+=-isystem$(shell$(CC)-print-file-name=include)ifeq ($(ARCH),arm)NEON_FLAGS+=-march=armv7-a-mfloat-abi=softfp-mfpu=neonendif
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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Aug 02, 2021 at 11:18:32AM -0700, Nathan Chancellor wrote:
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.
In practice, only stdarg.h was used, stdbool.h is trivial and SIMD
intrinsics are contained to a few architectures and aren't global
problem.
In general, kernel is very self contained code and -isystem removal
will further isolate it from Ring Threeland influence.
nds32 keeps -isystem globally due to intrisics used in entrenched header.
-isystem is selectively reenabled for some files.
Not compile tested on hexagon.
With this series on top of v5.14-rc4 and a tangential patch to fix
another issue, ARCH=hexagon defconfig and allmodconfig show no issues.
Tested-by: Nathan Chancellor <redacted> # build (hexagon)
On Mon, Aug 02, 2021 at 11:18:32AM -0700, Nathan Chancellor 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.
In practice, only stdarg.h was used, stdbool.h is trivial and SIMD
intrinsics are contained to a few architectures and aren't global
problem.
In general, kernel is very self contained code and -isystem removal
will further isolate it from Ring Threeland influence.
nds32 keeps -isystem globally due to intrisics used in entrenched header.
-isystem is selectively reenabled for some files.
Not compile tested on hexagon.
With this series on top of v5.14-rc4 and a tangential patch to fix
another issue, ARCH=hexagon defconfig and allmodconfig show no issues.
Tested-by: Nathan Chancellor <redacted> # build (hexagon)
Hexagon only builds with LLVM now because of the bump to require gcc
4.9: https://lore.kernel.org/r/20210623141854.GA32155@lst.de/
Brian Cain has a link in that thread to an LLVM toolchain that works
well for defconfig (allmodconfig requires LLVM 13/14 from git).
Otherwise, https://apt.llvm.org or LLVM from your package manager should
be sufficient for the same targets.
$ make -skj"$(nproc)" ARCH=hexagon CROSS_COMPILE=hexagon-linux-musl-
LLVM=1 LLVM_IAS=1 defconfig all
should work fine as long as the bin folder for whatever toolchain you
download is in your PATH.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Aug 02, 2021 at 11:30:00PM +0300, Alexey Dobriyan wrote:
On Mon, Aug 02, 2021 at 11:47:47AM -0500, Segher Boessenkool wrote:
quoted
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.
The kernel *has to* use those exact same types. So why on earth do you
feel you should reimplement this?
quoted
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.
It is a pretty tame file. And it works correctly for *all* targets,
including all Linux targets. Why reimplement this? No, it takes
virtually no resources to compile this. And you do not have to maintain
it *at all*, the compiler will take care of it. It is standard.
quoted
quoted
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.
???
That is there as well. But you want to remove it.
"The rest of GCC" is everything in cc1 (the compiler binary), in libgcc
(not that the kernel wants that either on most targets, although it is
required), etc. A few GB of binary goodness.
quoted
quoted
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.
s8 is a much nicer name, heh. But it could
#define s8 int8_t
certainly.
What I meant was the kernel wanted to avoid standard headers because
those traditionally have been a bit problematic. But decades have gone
by, and nowadays the kernel's own headers are at least as bad.
Also, -isystem removal disables <float.h> and <stdatomic.h> which is
desireable.
Why? Do you think #include <float.h> will ever make it past code
review? Do you need to throw up extra barriers so people will have a
harder time changing that policy, if ever they think that a good idea?
quoted
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.
Yes, where necessary, that is what I said. So, potentially everywhere.
An arch can decide to use some builtin in a generic header, for example.
Your patch makes for more work in the future, that is the best it does.
Segher
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel