Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210501151538.145449-1-masahiroy@kernel.org> <CANiq72k1hB3X6+Nc_iu=f=BoB-F9JW2j_B4ZMcv8_UpW5QQ2Og@mail.gmail.com>
 <3943bc020f6227c8801907317fc113aa13ad4bad.camel@perches.com>
 <65cda2bb-1b02-6ebc-0ea2-c48927524aa0@codethink.co.uk> <CANiq72mk84uay--BWOLT4zF12-rat9erohKazB8SpTPoVCTX1A@mail.gmail.com>
 <20210504092225.GS6564@kitsune.suse.cz>
In-Reply-To: <20210504092225.GS6564@kitsune.suse.cz>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Tue, 4 May 2021 14:09:24 +0200
Message-ID: <CANiq72kHwAeQ+vhFqg9tiQA-QHEK_xvP_Sro-_c5LJ2XDzjzxQ@mail.gmail.com>
Subject: Re: [PATCH] Raise the minimum GCC version to 5.2
To:     =?UTF-8?Q?Michal_Such=C3=A1nek?= <msuchanek@suse.de>
Cc:     Ben Dooks <ben.dooks@codethink.co.uk>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Arnd Bergmann <arnd@arndb.de>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Miguel Ojeda <ojeda@kernel.org>, Will Deacon <will@kernel.org>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Joe Perches <joe@perches.com>,
        Paul Mackerras <paulus@samba.org>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, May 4, 2021 at 11:22 AM Michal Such=C3=A1nek <msuchanek@suse.de> wr=
ote:
>
> Except it makes answering the question "Is this bug we see on this
> ancient system still present in upstream?" needlessly more difficult to
> answer.

Can you please provide some details? If you are talking about testing
a new kernel image in the ancient system "as-is", why wouldn't you
build it in a newer system? If you are talking about  particular
problems about bisecting (kernel, compiler) pairs etc., details would
also be welcome.

> Sure, throwing out old compiler versions that are known to cause
> problems makes sense. Updating to latest just because much less so.

I definitely did not argue for "latest compiler" or "updating just because"=
.

> One of the selling point of C in general and gcc in particular is
> stability. If we need the latest compiler we can as well rewrite the
> kernel in Rust which has a required update cycle of a few months.

Rust does not have a "required update cycle" and it does not break old
code unless really required, just like C and common compilers.

Concerning GCC, they patch releases for ~2.5 years, sure, but for many
projects that is not nearly enough. So you still need custom support,
which is anyway what most people care about.

> Because some mainline kernel features rely on bleeding edge tools I end
> up building mainline with current tools anyway but if you do not need
> BTF or whatever other latest gimmick older toolchains should do.

It would be better to hear concrete arguments about why "older
toolchains should do", rather than calling things a gimmick.

Cheers,
Miguel