All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Marco Elver <elver@google.com>,
	Michal Marek <michal.lkml@markovi.net>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
	linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org, Alex Shi <alexs@kernel.org>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Intel Graphics <intel-gfx@lists.freedesktop.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 10:40:38 -0800	[thread overview]
Message-ID: <CAHk-=wjU+DCbFG4nd3Wne-KbQ1n5=BHynv3xEmRYTaayBj-EfQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0CTmtUq+Uba2S3D7wjSstew2M+LfzZoOcKdKK9cfXO9A@mail.gmail.com>

On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change

I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user builds than for
the kernel. In fact, even not cross-building, we've had situations
where the "kbuild" compiler is different from the host compiler,
because people have upgraded one but not the other (upgrading the
kernel build environment is actually much easier than upgrading the
host build environment, because you don't need all the random
libraries etc, and you can literally _just_ build your own gcc and
binutils)

And we have *not* necessarily required that the host tools match the
kernel tools.

So I could well imagine that there are people who build their kernels,
but their host build environment might be old enough that -std=gnu11
is problematic for that part.

And note how any change to  KBUILD_USERCFLAGS is reflected in KBUILD_HOSTCFLAGS.

So I would suggest that the KBUILD_USERCFLAGS part of the patch (and
the modpost.c change that goes with it) be done as a separate commit.
Because we might end up reverting that part.

Hmm?

           Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	 Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev,  Jonathan Corbet <corbet@lwn.net>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>,  Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	 Nick Desaulniers <ndesaulniers@google.com>,
	 "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Intel Graphics <intel-gfx@lists.freedesktop.org>,
	 dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org,  linux-staging@lists.linux.dev,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	 Marco Elver <elver@google.com>
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 10:40:38 -0800	[thread overview]
Message-ID: <CAHk-=wjU+DCbFG4nd3Wne-KbQ1n5=BHynv3xEmRYTaayBj-EfQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0CTmtUq+Uba2S3D7wjSstew2M+LfzZoOcKdKK9cfXO9A@mail.gmail.com>

On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change

I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user builds than for
the kernel. In fact, even not cross-building, we've had situations
where the "kbuild" compiler is different from the host compiler,
because people have upgraded one but not the other (upgrading the
kernel build environment is actually much easier than upgrading the
host build environment, because you don't need all the random
libraries etc, and you can literally _just_ build your own gcc and
binutils)

And we have *not* necessarily required that the host tools match the
kernel tools.

So I could well imagine that there are people who build their kernels,
but their host build environment might be old enough that -std=gnu11
is problematic for that part.

And note how any change to  KBUILD_USERCFLAGS is reflected in KBUILD_HOSTCFLAGS.

So I would suggest that the KBUILD_USERCFLAGS part of the patch (and
the modpost.c change that goes with it) be done as a separate commit.
Because we might end up reverting that part.

Hmm?

           Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Marco Elver <elver@google.com>,
	Michal Marek <michal.lkml@markovi.net>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
	linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org, Alex Shi <alexs@kernel.org>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Intel Graphics <intel-gfx@lists.freedesktop.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 10:40:38 -0800	[thread overview]
Message-ID: <CAHk-=wjU+DCbFG4nd3Wne-KbQ1n5=BHynv3xEmRYTaayBj-EfQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0CTmtUq+Uba2S3D7wjSstew2M+LfzZoOcKdKK9cfXO9A@mail.gmail.com>

On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change

I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user builds than for
the kernel. In fact, even not cross-building, we've had situations
where the "kbuild" compiler is different from the host compiler,
because people have upgraded one but not the other (upgrading the
kernel build environment is actually much easier than upgrading the
host build environment, because you don't need all the random
libraries etc, and you can literally _just_ build your own gcc and
binutils)

And we have *not* necessarily required that the host tools match the
kernel tools.

So I could well imagine that there are people who build their kernels,
but their host build environment might be old enough that -std=gnu11
is problematic for that part.

And note how any change to  KBUILD_USERCFLAGS is reflected in KBUILD_HOSTCFLAGS.

So I would suggest that the KBUILD_USERCFLAGS part of the patch (and
the modpost.c change that goes with it) be done as a separate commit.
Because we might end up reverting that part.

Hmm?

           Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	 Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev,  Jonathan Corbet <corbet@lwn.net>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>,  Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	 Nick Desaulniers <ndesaulniers@google.com>,
	 "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Intel Graphics <intel-gfx@lists.freedesktop.org>,
	 dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org,  linux-staging@lists.linux.dev,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	 Marco Elver <elver@google.com>
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 10:40:38 -0800	[thread overview]
Message-ID: <CAHk-=wjU+DCbFG4nd3Wne-KbQ1n5=BHynv3xEmRYTaayBj-EfQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a0CTmtUq+Uba2S3D7wjSstew2M+LfzZoOcKdKK9cfXO9A@mail.gmail.com>

On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change

I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user builds than for
the kernel. In fact, even not cross-building, we've had situations
where the "kbuild" compiler is different from the host compiler,
because people have upgraded one but not the other (upgrading the
kernel build environment is actually much easier than upgrading the
host build environment, because you don't need all the random
libraries etc, and you can literally _just_ build your own gcc and
binutils)

And we have *not* necessarily required that the host tools match the
kernel tools.

So I could well imagine that there are people who build their kernels,
but their host build environment might be old enough that -std=gnu11
is problematic for that part.

And note how any change to  KBUILD_USERCFLAGS is reflected in KBUILD_HOSTCFLAGS.

So I would suggest that the KBUILD_USERCFLAGS part of the patch (and
the modpost.c change that goes with it) be done as a separate commit.
Because we might end up reverting that part.

Hmm?

           Linus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-02-28 18:41 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 10:27 [PATCH] [v2] Kbuild: move to -std=gnu11 Arnd Bergmann
2022-02-28 10:27 ` [Intel-gfx] " Arnd Bergmann
2022-02-28 10:27 ` Arnd Bergmann
2022-02-28 10:27 ` Arnd Bergmann
2022-02-28 10:50 ` Greg KH
2022-02-28 10:50   ` Greg KH
2022-02-28 10:50   ` [Intel-gfx] " Greg KH
2022-02-28 10:50   ` Greg KH
2022-02-28 11:25 ` Mark Rutland
2022-02-28 11:25   ` [Intel-gfx] " Mark Rutland
2022-02-28 11:25   ` Mark Rutland
2022-02-28 11:25   ` Mark Rutland
2022-02-28 11:37   ` Arnd Bergmann
2022-02-28 11:37     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 11:37     ` Arnd Bergmann
2022-02-28 11:37     ` Arnd Bergmann
2022-02-28 18:40     ` Linus Torvalds [this message]
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 17:07   ` Masahiro Yamada
2022-02-28 17:07     ` [Intel-gfx] " Masahiro Yamada
2022-02-28 17:07     ` Masahiro Yamada
2022-02-28 17:07     ` Masahiro Yamada
2022-02-28 11:47 ` Marco Elver
2022-02-28 11:47   ` [Intel-gfx] " Marco Elver
2022-02-28 11:47   ` Marco Elver
2022-02-28 11:47   ` Marco Elver
2022-02-28 11:57   ` Arnd Bergmann
2022-02-28 11:57     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 11:57     ` Arnd Bergmann
2022-02-28 11:57     ` Arnd Bergmann
2022-02-28 16:56     ` Nathan Chancellor
2022-02-28 16:56       ` [Intel-gfx] " Nathan Chancellor
2022-02-28 16:56       ` Nathan Chancellor
2022-02-28 16:56       ` Nathan Chancellor
2022-02-28 12:36 ` Jani Nikula
2022-02-28 12:36   ` Jani Nikula
2022-02-28 12:36   ` [Intel-gfx] " Jani Nikula
2022-02-28 12:36   ` Jani Nikula
2022-02-28 13:01   ` Arnd Bergmann
2022-02-28 13:01     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 13:01     ` Arnd Bergmann
2022-02-28 13:01     ` Arnd Bergmann
2022-02-28 13:19     ` David Sterba
2022-02-28 13:19       ` David Sterba
2022-02-28 13:19       ` [Intel-gfx] " David Sterba
2022-02-28 13:19       ` David Sterba
2022-02-28 12:48 ` Alex Shi
2022-02-28 12:48   ` Alex Shi
2022-02-28 12:48   ` [Intel-gfx] " Alex Shi
2022-02-28 12:48   ` Alex Shi
2022-02-28 12:56 ` David Sterba
2022-02-28 12:56   ` David Sterba
2022-02-28 12:56   ` [Intel-gfx] " David Sterba
2022-02-28 12:56   ` David Sterba
2022-02-28 17:02 ` Masahiro Yamada
2022-02-28 17:02   ` [Intel-gfx] " Masahiro Yamada
2022-02-28 17:02   ` Masahiro Yamada
2022-02-28 17:02   ` Masahiro Yamada
2022-02-28 18:24   ` Arnd Bergmann
2022-02-28 18:24     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 18:24     ` Arnd Bergmann
2022-02-28 18:24     ` Arnd Bergmann
2022-02-28 21:03 ` Nick Desaulniers
2022-02-28 21:03   ` Nick Desaulniers
2022-02-28 21:03   ` [Intel-gfx] " Nick Desaulniers
2022-02-28 21:03   ` Nick Desaulniers
2022-02-28 21:41   ` Fangrui Song
2022-02-28 21:41     ` [Intel-gfx] " Fangrui Song
2022-02-28 21:41     ` Fangrui Song
2022-02-28 21:41     ` Fangrui Song
2022-03-01 14:45     ` Arnd Bergmann
2022-03-01 14:45       ` [Intel-gfx] " Arnd Bergmann
2022-03-01 14:45       ` Arnd Bergmann
2022-03-01 14:45       ` Arnd Bergmann
2022-02-28 21:41 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-02-28 22:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-01  7:30 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-01 10:24 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Kbuild: move to -std=gnu11 (rev2) Patchwork
2022-03-01 10:43 ` [PATCH] [v2] Kbuild: move to -std=gnu11 Miguel Ojeda
2022-03-01 10:43   ` [Intel-gfx] " Miguel Ojeda
2022-03-01 10:43   ` Miguel Ojeda
2022-03-01 10:43   ` Miguel Ojeda
2022-03-01 14:44   ` Arnd Bergmann
2022-03-01 14:44     ` [Intel-gfx] " Arnd Bergmann
2022-03-01 14:44     ` Arnd Bergmann
2022-03-01 14:44     ` Arnd Bergmann
2022-03-01 10:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Kbuild: move to -std=gnu11 (rev2) Patchwork
2022-03-01 17:22 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-05-16 13:10 ` [PATCH] [v2] Kbuild: move to -std=gnu11 Guenter Roeck
2022-05-16 13:10   ` Guenter Roeck
2022-05-16 13:10   ` [Intel-gfx] " Guenter Roeck
2022-05-16 13:10   ` Guenter Roeck
2022-05-16 13:31   ` [greybus-dev] " Greg KH
2022-05-16 13:31     ` Greg KH
2022-05-16 13:31     ` [Intel-gfx] " Greg KH
2022-05-16 13:31     ` Greg KH
2022-05-16 14:19     ` Guenter Roeck
2022-05-16 14:19       ` Guenter Roeck
2022-05-16 14:19       ` [Intel-gfx] " Guenter Roeck
2022-05-16 14:19       ` Guenter Roeck
2022-05-18  7:46       ` Arnd Bergmann
2022-05-18  7:46         ` Arnd Bergmann
2022-05-18  7:46         ` Arnd Bergmann
2022-05-18 14:07         ` Guenter Roeck
2022-05-18 14:07           ` Guenter Roeck
2022-05-18 14:07           ` [Intel-gfx] " Guenter Roeck
2022-05-18 14:07           ` Guenter Roeck

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='CAHk-=wjU+DCbFG4nd3Wne-KbQ1n5=BHynv3xEmRYTaayBj-EfQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=alexs@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=elver@google.com \
    --cc=federico.vaga@vaga.pv.it \
    --cc=greybus-dev@lists.linaro.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-doc-tw-discuss@lists.sourceforge.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=ndesaulniers@google.com \
    --cc=src.res@email.cn \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.