LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: akpm@linux-foundation.org, linux-arch@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	masahiroy@kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/3] isystem: delete global -isystem compile option
Date: Mon, 2 Aug 2021 16:42:07 -0500	[thread overview]
Message-ID: <20210802214207.GP1583@gate.crashing.org> (raw)
In-Reply-To: <YQhVyOdQKUnvz1n5@localhost.localdomain>

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

  reply	other threads:[~2021-08-02 21:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-01 20:13 [PATCH 1/3] isystem: trim/fixup stdarg.h and other headers Alexey Dobriyan
2021-08-01 20:13 ` [PATCH 2/3] isystem: ship and use stdarg.h Alexey Dobriyan
2021-08-03  7:14   ` Ard Biesheuvel
2021-08-17  1:30     ` Masahiro Yamada
2021-08-06 13:00   ` Rafael J. Wysocki
2021-08-01 20:13 ` [PATCH 3/3] isystem: delete global -isystem compile option Alexey Dobriyan
2021-08-01 21:32   ` Segher Boessenkool
2021-08-02  6:42     ` Alexey Dobriyan
2021-08-02 16:47       ` Segher Boessenkool
2021-08-02 20:30         ` Alexey Dobriyan
2021-08-02 21:42           ` Segher Boessenkool [this message]
2021-08-02  1:30   ` kernel test robot
2021-08-02 18:18   ` Nathan Chancellor
2021-08-02 20:32     ` Alexey Dobriyan
2021-08-02 20:38       ` Nathan Chancellor
2021-08-02  0:21 ` [PATCH 1/3] isystem: trim/fixup stdarg.h and other headers kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210802214207.GP1583@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=masahiroy@kernel.org \
    --cc=paulus@samba.org \
    --cc=will@kernel.org \
    --subject='Re: [PATCH 3/3] isystem: delete global -isystem compile option' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).