Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 25 Apr 2022 13:43:14 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: odd endianness toolchains for crosstool
Message-ID: <YmaJUvg6hmekvkXE@zx2c4.com>
References: <YmX7z+BirkA3VAfW@zx2c4.com>
 <CAK8P3a3Af5FBx-OnedHPrf28ikX4DZK1d0ERLsV+oKyBHyCXiw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAK8P3a3Af5FBx-OnedHPrf28ikX4DZK1d0ERLsV+oKyBHyCXiw@mail.gmail.com>
Precedence: bulk

Hi Arnd,

On Mon, Apr 25, 2022 at 10:46:45AM +0200, Arnd Bergmann wrote:
> The situation on my end is that I'm planning to migrate my main workstation
> (which I'm building the compilers on) to an arm64 machine soon, and
> will then need to set it all up again. I don't really want to change much before
> then to avoid changing things twice.

Ahh, okay, so probably crosstool won't be viable for me for a while. Are
your existing scripts fairly reproducible and easy? I suppose I could
just build my own if I can't find another project supplying light
compilers.

> I've added Nick to Cc, as he's experimenting with a clang based toolchain
> that we can put on kernel.org along with the gcc toolchains, and that
> would probably include a musl based sysroot roughly the same set of
> architectures that you are testing on already. Possibly we could reuse the
> same user space between clang and gcc.

I personally have no use for compilers with user spaces. My test harness
builds musl as part of it. It's really the quickest part of the entire
harness to build. I also probably won't switch things over to clang;
Google has the resources to do that themselves. Basically all I need is
the boring nolibc compilers for a few extra platforms, and for the ppc
one to build with the mentioned flags.

> I've also looked at other projects that do qemu based testing, everyone
> seems to be missing one or two architectures out of a common set,
> https://tinyurl.com/linux-architectures is where I keep my data.

If the compilers are there, and they can build a working musl, and QEMU
will boot it, and I can work out a minimal kernel .config that doesn't
take a long time to compile, then it'll get included in the CI. So in
theory, I should be able to expand the portfolio of architectures I'm
using.

> building and running the most common subset of these in one place
> in the kernel tree where at least wireguard, kunit and tuxrun can
> share the setup for qemu.

I have little interest in that kind of abstraction unfortunately.
WireGuard's test suite is optimized for building minimal kernels that
exercise its functionality. Tons of emphasis is placed on those kernels
being minimal. And the userspaces too. The whole thing needs to compile
fast and boot fast. Perhaps megacorps can afford to throw massive
clusters at this, but I'm trying to test every single commit across 10
or so trees on every architecture that I can, from one box. Plus, I use
this when developing on my laptop. If it takes forever to build and if I
can't iterate fast on it, then it's simply not useful for me (or for
other various contributors who have been able to quickly pick up the
WireGuard test suite for development without a lot of futzing). So for
that reason, I don't see a lot of promise in making a monster
abstraction layer that does all the things. Plus, the more people who
invent the wheel (which is not even a particularly interesting wheel)
the more odd configurations and bugs we'll surface.

Jason