Message-ID: <CANiq72m1EKmNM4QQ_A08vC2w-4QbHhO5UEG4F68tRGKEgZ9p6g@mail.gmail.com>
Date: Tue, 14 Oct 2025 17:42:45 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Guillaume Tucker <gtucker@...cker.io>
Cc: Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Miguel Ojeda <ojeda@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	automated-testing@...ts.yoctoproject.org, Arnd Bergmann <arnd@...db.de>, 
	workflows@...r.kernel.org, llvm@...ts.linux.dev, 
	David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>, Shuah Khan <shuah@...nel.org>
Subject: Re: [RFC PATCH 1/1] kbuild: add Makefile.container with CONTAINER option

On Tue, Oct 14, 2025 at 4:31 PM Guillaume Tucker <gtucker@...cker.io> wrote:
>
> This is what the CONTAINER_COMMAND variable is for.  You can easily
> set it in the environment e.g. `export CONTAINER_COMMAND=podman` or
> anything and be done with it.  The default is set to `docker`.

Yeah, that is what I mean, i.e. you have to more variables to make it
do what you want.

At that point, a user could also equally set up an alias or a quick
one liner script to call the real command with whatever setup they
need. That would be more flexible too with essentially the same
complexity on their side.

> As
> far as I know, there's no need for anything else than the container
> command and image name.  So it's not more hard-coded than say, the
> default $(CC) executable.

There is the `src` path there, no? e.g. I use upstream distro images
to test some builds.

> Then I was only suggesting using a minimalist alias e.g.:
>
>      alias kmake='make -f scripts/Makefile.container'

Yeah, what I was trying to say is that, at that point, you can just
have an alias (or a one liner script etc.) for the real command.

The user still needs to know how to use Docker/Podman/... anyway, i.e.
I would see the benefit if somehow this was the only command they
would need or if this handled some extra logic.

> hand with a volume and then run make inside.  It reduces the scope
> for differences and makes builds more reproducible, for example you
> can just share your command line and others will be using the exact
> same toolchain and build environment as you.  This is also to enable
> developers to easily reproduce builds from CI bots.  It's been one of
> the driving principles behind tuxmake except I'm looking at it from a
> neutral point of view here.  In other words, it's a step towards
> increasing quality control upstream.

Definitely, I am not saying containers are a bad idea (I use them
myself), i.e. I am only talking about what is the best way to provide
this (e.g. documentation, a script, this new file, directly in the
main `Makefile`...).

> A related topic which was covered at Plumbers is to have first-party
> container images, with Containerfiles maintained upstream to
> facilitate using the kernel.org toolchains.  It's not a requirement
> for this patch but both ideas enhance each other.

kernel.org images would be nice, indeed.

> Yes, I did think of writing a documentation page alongside this patch
> but eventually made the RFC with a cover letter instead to keep it
> more as an open discussion.  Any solution to run containerized builds
> would need to be documented, even if they're trivial to use.  I think
> the Makefile approach is the most elegant one but if others aren't
> convinced by it then starting with just some documentation might help
> getting to the bottom of this and decide what to do next.

Yeah, docs would be nice regardless of the way of wrapping it.

> Right but then I think we would have to deal with the variables
> handled by `make` which can be passed either via the environment or
> on the command line, so that's similar to the issues with an alias.

The script may be more involved, i.e. similar to the KUnit one, but
then you also gain the ability to provide more functionality/logic.

Say, for instance, the ability to test with a set of container images
that you define in the config file, to run certain things with the
built kernel (possibly in another container), and so on and so forth.

> We could do something like with Android builds (build/envsetup.sh)
> with a file to source:
>
>      . scripts/containerize
>      m CONTAINER=korg-clang:21 defconfig
>
> where `m` is just an arbitrary alias name obviously :)

Personally, for a new script, I would use a normal `--flags` like
interface, and leave the Make-like one if one wants to pass the actual
Make ones. I would also allow the user to define a default image too
in their config file too, and things like that.

In other words, the idea is that you can actually easily use it
without typing a lot, e.g.

    scripts/container b defconfig

(Possibly aliasing `scripts/container` itself to something shorter locally)

Or even more high-level operations like the "build with my set of
toolchain images", "build patch by patch this range of commits inside
the container", etc.

But I know this may be way out of scope :) After all, it gets into the
realm of essentially a lot of the custom tooling/scripts that
different subsystems build for themselves over time.

In fact, another possibility to think about is generalizing the
existing KUnit one to support containers.

> Thank you for your feedback.  I can spend some time investigating
> alternative approaches if they seem worthwhile.  I'd be interested to
> know what others think of this too.

You're welcome! I hope that helped at least.

Cc'ing David/Rae/Shuah as well for the KUnit bits.

Cheers,
Miguel

Powered by blists - more mailing lists