Message-ID: <29c33635-cd83-4a47-aea0-460f196f1e3a@gtucker.io>
Date: Tue, 14 Oct 2025 16:42:44 +0200
From: Guillaume Tucker <gtucker@...cker.io>
To: Onur Özkan <work@...rozkan.dev>,
 Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
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
Subject: Re: [RFC PATCH 1/1] kbuild: add Makefile.container with CONTAINER
 option

Hi Onur,

On 14/10/2025 4:08 pm, Onur Özkan wrote:
> On Tue, 14 Oct 2025 13:58:10 +0200
> Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:
> 
>> On Tue, Oct 14, 2025 at 11:45 AM Guillaume Tucker
>> <gtucker@...cker.io> wrote:
>>>
>>> Add scripts/Makefile.container to wrap the make command in a
>>> container using the CONTAINER= variable to specify the image name.
>>> For example:
>>>
>>>      make -f scripts/Makefile.container CONTAINER=korg-gcc defconfig
>>>
>>> The container image name is entirely arbitrary and the container
>>> tool may be Docker, Podman or any other compatible alternative
>>> specified by the CONTAINER_COMMAND variable.  The default is set to
>>> docker for now.
>>
>> IIUC, this wraps reruns `make` inside the container, but it means
>> hardcoding a particular tool and path, right? (unless one sets even
>> more variables)
>>
>> The cover letter says one can create an alias for this, but one could
>> also do that for the underlying call anyway, unless I am missing
>> something. And if we do this, then I would prefer one doesn't need to
>> type `-f ...`.
>>
>> Put another way, for a user, what is the benefit of having this extra
>> way of running in a container? For instance, I could see the benefit
>> if different tools had different flags or it was a complicated
>> procedure, but I think at least `podman` shares the flags used here.
>>
>> Should this instead be a document inside `Documentation/` somewhere
>> that explains how to do this, pitfalls, advanced options, etc. and
>> give example command lines for different tools?
>>
>> If we do end up with `CONTAINER=`, then I think it should make it work
>> without having to pass `-f ...`, to make it easier. Or, even better,
>> like the KUnit script, we could have a script that does the right
>> thing and reads a config from the user, so that one can just type
>> something like, picking whatever tooling the user configured (e.g.
>> Docker vs. Podman, default image, etc.):
>>
>>      scripts/container.py defconfig
>>
> 
> I think this functionality would be better implemented as a script
> (like you mentioned) rather than a Makefile. The current approach is
> likely to run into several practical issues (e.g. file permission
> mismatches between host and container, the need to manually remove
> containers with `docker rm`, etc.) and addressing all of these
> reliably in Makefile can become quite messy. Writing a python (or even
> perl) script would make it much easier to maintain. Also, it can be
> self-documented quite nicely with `scripts/container.py --help` command.

Our emails have crossed - OK I'll take a look into this.  I fear a
script is actually going to be more difficult to maintain and will
require additional dependencies on the host i.e. Python.  But like I
wrote in my previous email, I'm happy to consider some alternatives
and see if we can find a consensus.

The issue with file ownership can be addressed with user id mapping
in principle.  Garbage collecting containers is not something I've
looked into as it's not a new problem compared to starting containers
explicitly.  I'll keep these things in mind too when comparing
solutions.

Thanks,
Guillaume

Powered by blists - more mailing lists