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: > > 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? > > > 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. > > > 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. > > > 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? > > > 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
