* Re: Hosting first-party kernel.org container images
From: Guillaume Tucker @ 2026-06-25 12:31 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Ben Copeland, Konstantin Ryabitsev, Miguel Ojeda,
Nathan Chancellor, Nicolas Schier, Arnd Bergmann, Onur Özkan,
linux-kernel@vger.kernel.org, workflows, automated-testing,
kernelci@lists.linux.dev
In-Reply-To: <CANiq72=t=q4__vwTFjg+gQyjKLUEJrZBngr3cAnnKiTNM5uteg@mail.gmail.com>
Hi Miguel,
(sorry, picking this up again after a long pause)
On 19/03/2026 12:10, Miguel Ojeda wrote:
> On Wed, Feb 25, 2026 at 3:44 PM Guillaume Tucker <gtucker@gtucker.io> wrote:
>>
>> Nathan, Nicolas, Miguel - what are your thoughts on this?
>
> I agree with Nathan that `Containerfile`s on git.kernel.org sounds good.
Thanks for your feedback. My understanding of Nathan's reply is that
it's more about looking for what users need in practice to drive
decisions rather than any strong opinion regarding this approach, but
I think we all agree at some level.
> While many kernel developers may not use them (mostly because everyone
> has their own setup already), if we had a set of "base" images that
> are maintained by someone trusted (including publishing them in the
> usual registries for easy use), then I think a bunch of us would
> actually use them for CI and possibly other tasks; just like some of
> us already use the kernel.org toolchains "manually" anyway etc.
>
> It could serve as an entry point to discover the different toolchains
> and software offered by kernel.org, i.e. not just the GCC and LLVM and
> LLVM+Rust toolchains, but also perhaps `b4` pre-installed and so on.
> Even things like `tc-build` or the latest and greatest set of AI
> context text files could be considered too.
>
> It could also perhaps simplify a tiny bit giving quick reproducers
> compared to giving the instructions for a distro base image + extra
> things to install. It could also be a good thing to give newcomers
> (i.e. how to set up all the development environment is a common
> question) and LLMs.
>
> I mean, all this is nothing new of course, but sometimes trust and
> convenience go a long way.
Yes I believe there's a solid list of reasons why this would be a
good thing to have, and also no compelling reason to do it right now.
As I happen to have some R&D time available to spend on this again,
we can resume progress and aim for a first goal.
What I'm proposing next is to make it trivial for developers to use
scripts/container with the TuxMake images that include the kernel.org
toolchains via either built-in defaults in the tool or a standard
user config file. I'm under the impression that at least a few
people have started using the tool so I think there's a real growing
interest there. The TuxMake images can further facilitate adoption.
Then as a separate initiative, we can consider keeping Containerfiles
on git.kernel.org if developers feel it would make sense and maybe
even images in a dedicated registry. These things aren't on the
critical path for using the tool, they're more like potential
consequences of people using it. So we'll see how this goes.
Best wishes,
Guillaume
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox