Re: Migration to Debian Bookworm and compiler updates for KernelCI

Guillaume Tucker <[email protected]>
Newsgroups dev.linux.lists.kernelci,dev.linux.lists.llvm
Message-ID <[email protected]>
Hello,

On 07/03/2024 6:05 pm, Nathan Chancellor wrote:
> Hi Denys,
> 
> On Thu, Mar 07, 2024 at 01:02:26PM +0200, Denys Fedoryshchenko wrote:
>> Hello,
>>
>> I'm reaching out on behalf of the KernelCI project team to discuss our
>> current compiler setup and planned migration to Debian Bookworm.
>>
>> As you may know, our compiler images are currently based on Debian
>> Bullseye, which is approaching its end of life in July 2024. We have
>> been testing using gcc-10, which has presented us with some recent
>> challenges, notably a significant bug that results in false positive
>> compilation errors (specifically, the -Werror memcpy issue in
>> security.c). This situation has prompted us to consider an urgent
>> migration to Debian Bookworm. Additionally, the migration is
>> necessitated by our requirement to upgrade to a newer Python version to
>> support KernelCI v2 development efforts.
>>
>> However, before we proceed, we have a couple of pending questions that
>> we hope to get clarity on:
>>
>> 1) We've noticed that the minimal available version of clang on
>> https://apt.llvm.org/bookworm/dists/ is 15, whereas our current minimal
>> requirement for the Linux kernel compilation is clang-13.0.1
>> (https://www.kernel.org/doc/html/next/process/changes.html). How
>> critical is it to continue providing compile tests for clang-13 (and
>> potentially clang-14)? This information would be vital for us in
>> planning our compiler support strategy moving forward.
> 
> Coverage of the minimum version of a particular toolchain for building
> the kernel is important but I would not describe it as critical.
> 
> While apt.llvm.org's Bookworm distribution does not have clang-13 and
> clang-14, the Bullseye distribution of clang-13 and clang-14 does work
> on Bookworm, I personally do that for my Debian development containers:
> 
> https://github.com/nathanchance/env/blob/12927502f12ec63f50a460f842c9d0a70a82c629/podman/dev/debian/setup-env.sh#L54-L64
> 
> Have you explored using the kernel.org GCC and LLVM toolchains instead
> of the ones in Debian?
> 
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
> https://mirrors.edge.kernel.org/pub/tools/llvm/
> 
> That would potentially give you more flexibility with distribution
> upgrades and stable/deterministic compiler versions around that. I
> maintain the LLVM ones, which are optimized at build time to be quicker
> than the Debian one's, so that would save you build minutes over time.

Ah nice, Arnd suggested a while ago that we used his GCC
cross-compiler toolchains in KernelCI but it got stuck at a
slightly lower priority than everything else for core developers.
It has always been considered a nice thing to do one day, and I
guess there may be additional reasons to pick it up now with the
need for a wider GCC version coverage and LLVM/Clang too.

Out of interest, is there going to be some Rust toolchains there
as well?  Having all the reference toolchains to build the kernel
in a single location would be great I think.  Of course Rust
support is still a moving target, so maybe it's still a bit too
early right now - just wondering.

Then in addition to the tarballs, one thing that was discussed
with Linaro in the very early days of tuxmake was to have a
reference set of Docker image with the toolchains already
installed - to save everyone creating their own like in Nathan's
GitHub link.  Has anyone done that already?

I started looking into it while I was writing my tutorial to
build a kernel last month but didn't find anything, so it's kind
of going up on my TODO list now.  It would greatly help unify
kernel builds across CI systems in particular and improve
reproducibility.  The TuxBuild / tuxmake Docker images were
forked from the KernelCI ones so that's already something that
could be reunited at some point.

Cheers,
Guillaume
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.