Add a dev-tools/container.rst documentation page for the
scripts/container tool.  This covers the basic usage with additional
information about environment variables and user IDs.  It also
includes a number of practical examples with a reference to the
experimental kernel.org toolchain images.

Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: David Gow <davidgow@google.com>
Cc: "Onur Özkan" <work@onurozkan.dev>
Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
---
 Documentation/dev-tools/container.rst | 201 ++++++++++++++++++++++++++
 Documentation/dev-tools/index.rst     |   1 +
 2 files changed, 202 insertions(+)
 create mode 100644 Documentation/dev-tools/container.rst

diff --git a/Documentation/dev-tools/container.rst b/Documentation/dev-tools/container.rst
new file mode 100644
index 000000000000..f6f134ec09f5
--- /dev/null
+++ b/Documentation/dev-tools/container.rst
@@ -0,0 +1,201 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2025 Guillaume Tucker
+
+====================
+Containerized Builds
+====================
+
+The ``container`` tool can be used to run any command in the kernel source tree
+from within a container.  Doing so facilitates reproducing builds across
+various platforms, for example when a test bot has reported an issue which
+requires a specific version of a compiler or an external test suite.  While
+this can already be done by users who are familiar with containers, having a
+dedicated tool in the kernel tree lowers the barrier to entry by solving common
+problems once and for all (e.g. user id management).  It also makes it easier
+to share an exact command line leading to a particular result.  The main use
+case is likely to be kernel builds but virtually anything can be run: KUnit,
+checkpatch etc. provided a suitable image is available.
+
+
+Options
+=======
+
+Command line syntax::
+
+  scripts/container -i IMAGE [OPTION]... CMD...
+
+Available options:
+
+``-e, --env-file ENV_FILE``
+
+    Path to an environment file to load in the container.
+
+``-g, --gid GID``
+
+    Group id to use inside the container.
+
+``-i, --image IMAGE``
+
+    Container image name (required).
+
+``-r, --runtime RUNTIME``
+
+    Container runtime name.  Supported runtimes: ``docker``, ``podman``.
+
+    If not specified, the first one found on the system will be used
+    i.e. Docker if present, otherwise Podman.
+
+``-s, --shell``
+
+    Run the container in an interactive shell.
+
+``-u, --uid UID``
+
+    User id to use inside the container.
+
+    If the ``-g`` option is not specified, the user id will also be used for
+    the group id.
+
+``-v, --verbose``
+
+    Enable verbose output.
+
+``-h, --help``
+
+    Show the help message and exit.
+
+
+Usage
+=====
+
+It's entirely up to the user to choose which image to use and the ``CMD``
+arguments are passed directly as an arbitrary command line to run in the
+container.  The tool will take care of mounting the source tree as the current
+working directory and adjust the user and group id as needed.
+
+The container image which would typically include a compiler toolchain is
+provided by the user and selected via the ``-i`` option.  The container runtime
+can be selected with the ``-r`` option, which can be either ``docker`` or
+``podman``.  If none is specified, the first one found on the system will be
+used.  Support for other runtimes may be added later depending on their
+popularity among users.
+
+By default, commands are run non-interactively.  The user can abort a running
+container with SIGINT (Ctrl-C).  To run commands interactively with a TTY, the
+``--shell`` or ``-s`` option can be used.  Signals will then be received by the
+shell directly rather than the parent ``container`` process.  To exit an
+interactive shell, use Ctrl-D or ``exit``.
+
+.. note::
+
+   The only host requirement aside from a container runtime is Python 3.10 or
+   later.
+
+
+Environment Variables
+=====================
+
+Environment variables are not propagated to the container so they have to be
+either defined in the image itself or via the ``-e`` option using an
+environment file.  In some cases it makes more sense to have them defined in
+the Containerfile used to create the image.  For example, a Clang-only compiler
+toolchain image may have ``LLVM=1`` defined.
+
+The local environment file is more useful for user-specific variables added
+during development.  It is passed as-is to the container runtime so its format
+may vary.  Typically, it will look like the output of ``env``.  For example::
+
+  INSTALL_MOD_STRIP=1
+  SOME_RANDOM_TEXT=One upon a time
+
+Please also note that ``make`` options can still be passed on the command line,
+so while this can't be done since the first argument needs to be the
+executable::
+
+  scripts/container -i tuxmake/korg-clang LLVM=1 make
+
+this will work::
+
+  scripts/container -i tuxmake/korg-clang make LLVM=1
+
+
+User IDs
+========
+
+This is an area where the behaviour will vary slightly depending on the
+container runtime.  The goal is to run commands as the user invoking the tool.
+With Podman, a namespace is created to map the current user id to a different
+one in the container (1000 by default).  With Docker, while this is also
+possible with recent versions it requires a special feature to be enabled in
+the daemon so it's not used here for simplicity.  Instead, the container is run
+with the current user id directly.  In both cases, this will provide the same
+file permissions for the kernel source tree mounted as a volume.  The only
+difference is that when using Docker without a namespace, the user id may not
+be the same as the default one set in the image.
+
+Say, we're using an image which sets up a default user with id 1000 and the
+current user calling the ``container`` tool has id 1234.  The kernel source
+tree was checked out by this same user so the files belong to user 1234.  With
+Podman, the container will be running as user id 1000 with a mapping to id 1234
+so that the files from the mounted volume appear to belong to id 1000 inside
+the container.  With Docker and no namespace, the container will be running
+with user id 1234 which can access the files in the volume but not in the user
+1000 home directory.  This shouldn't be an issue when running commands only in
+the kernel tree but it is worth highlighting here as it might matter for
+special corner cases.
+
+
+Examples
+========
+
+The shortest example is to run a basic kernel build using the default runtime
+(e.g. Docker) and a ``tuxmake`` Clang image::
+
+  scripts/container -i tuxmake/korg-clang -- make LLVM=1 defconfig
+  scripts/container -i tuxmake/korg-clang -- make LLVM=1 -j$(nproc)
+
+.. note::
+
+   When running a command with options within the container, it should be
+   separated with a double dash ``--`` to not confuse them with the
+   ``container`` tool options.  Plain commands with no options don't strictly
+   require the double dashes e.g.::
+
+     scripts/container -i tuxmake/korg-clang make mrproper
+
+To run ``checkpatch.pl`` in a ``patches`` directory with a generic image::
+
+  scripts/container -i perl:slim-trixie scripts/checkpatch.pl patches/*
+
+The examples below refer to ``kernel.org`` images which are based on the
+`kernel.org compiler toolchains
+<https://mirrors.edge.kernel.org/pub/tools/>`__.  These aren't (yet) officially
+available in any public registry but users can build their own locally instead
+using this `experimental repository
+<https://gitlab.com/gtucker/korg-containers>`__ by running ``make
+PREFIX=kernel.org/``.
+
+To build just ``bzImage`` using Clang::
+
+  scripts/container -i kernel.org/clang -- make bzImage -j$(nproc)
+
+Same with GCC 15 as a particular version tag::
+
+  scripts/container -i kernel.org/gcc:15 -- make bzImage -j$(nproc)
+
+To run KUnit in an interactive shell and get the full output::
+
+  scripts/container -s -i kernel.org/gcc:kunit -- \
+      tools/testing/kunit/kunit.py \
+          run \
+          --arch=x86_64 \
+          --cross_compile=x86_64-linux-
+
+To just start an interactive shell::
+
+  scripts/container -si kernel.org/gcc bash
+
+To build the HTML documentation, which requires the ``kdocs`` image built with
+``make PREFIX=kernel.org/ extra`` as it's not a compiler toolchain::
+
+  scripts/container -i kernel.org/kdocs make htmldocs
diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
index 4b8425e348ab..527a0e4cf2ed 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -38,6 +38,7 @@ Documentation/process/debugging/index.rst
    gpio-sloppy-logic-analyzer
    autofdo
    propeller
+   container
 
 
 .. only::  subproject and html
-- 
2.47.3

On Wed, Dec 31, 2025 at 05:51:50PM +0100, Guillaume Tucker wrote:
> Add a dev-tools/container.rst documentation page for the
> scripts/container tool.  This covers the basic usage with additional
> information about environment variables and user IDs.  It also
> includes a number of practical examples with a reference to the
> experimental kernel.org toolchain images.
> 
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Cc: David Gow <davidgow@google.com>
> Cc: "Onur Özkan" <work@onurozkan.dev>
> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
> ---
>  Documentation/dev-tools/container.rst | 201 ++++++++++++++++++++++++++
>  Documentation/dev-tools/index.rst     |   1 +
>  2 files changed, 202 insertions(+)
>  create mode 100644 Documentation/dev-tools/container.rst
> 
> diff --git a/Documentation/dev-tools/container.rst b/Documentation/dev-tools/container.rst
> new file mode 100644
> index 000000000000..f6f134ec09f5
> --- /dev/null
> +++ b/Documentation/dev-tools/container.rst
> @@ -0,0 +1,201 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +.. Copyright (C) 2025 Guillaume Tucker
> +
> +====================
> +Containerized Builds
> +====================
> +
> +The ``container`` tool can be used to run any command in the kernel source tree
> +from within a container.  Doing so facilitates reproducing builds across
> +various platforms, for example when a test bot has reported an issue which
> +requires a specific version of a compiler or an external test suite.  While
> +this can already be done by users who are familiar with containers, having a
> +dedicated tool in the kernel tree lowers the barrier to entry by solving common
> +problems once and for all (e.g. user id management).  It also makes it easier
> +to share an exact command line leading to a particular result.  The main use
> +case is likely to be kernel builds but virtually anything can be run: KUnit,
> +checkpatch etc. provided a suitable image is available.
> +
> +
> +Options
> +=======
> +
> +Command line syntax::
> +
> +  scripts/container -i IMAGE [OPTION]... CMD...
> +
> +Available options:
> +
> +``-e, --env-file ENV_FILE``
> +
> +    Path to an environment file to load in the container.
> +
> +``-g, --gid GID``
> +
> +    Group id to use inside the container.
> +
> +``-i, --image IMAGE``
> +
> +    Container image name (required).
> +
> +``-r, --runtime RUNTIME``
> +
> +    Container runtime name.  Supported runtimes: ``docker``, ``podman``.
> +
> +    If not specified, the first one found on the system will be used
> +    i.e. Docker if present, otherwise Podman.
> +
> +``-s, --shell``
> +
> +    Run the container in an interactive shell.
> +
> +``-u, --uid UID``
> +
> +    User id to use inside the container.
> +
> +    If the ``-g`` option is not specified, the user id will also be used for
> +    the group id.
> +
> +``-v, --verbose``
> +
> +    Enable verbose output.
> +
> +``-h, --help``
> +
> +    Show the help message and exit.
> +
> +
> +Usage
> +=====
> +
> +It's entirely up to the user to choose which image to use and the ``CMD``
> +arguments are passed directly as an arbitrary command line to run in the
> +container.  The tool will take care of mounting the source tree as the current
> +working directory and adjust the user and group id as needed.
> +
> +The container image which would typically include a compiler toolchain is
> +provided by the user and selected via the ``-i`` option.  The container runtime
> +can be selected with the ``-r`` option, which can be either ``docker`` or
> +``podman``.  If none is specified, the first one found on the system will be
> +used.  Support for other runtimes may be added later depending on their
> +popularity among users.
> +
> +By default, commands are run non-interactively.  The user can abort a running
> +container with SIGINT (Ctrl-C).  To run commands interactively with a TTY, the
> +``--shell`` or ``-s`` option can be used.  Signals will then be received by the
> +shell directly rather than the parent ``container`` process.  To exit an
> +interactive shell, use Ctrl-D or ``exit``.
> +
> +.. note::
> +
> +   The only host requirement aside from a container runtime is Python 3.10 or
> +   later.
> +
> +
> +Environment Variables
> +=====================
> +
> +Environment variables are not propagated to the container so they have to be
> +either defined in the image itself or via the ``-e`` option using an
> +environment file.  In some cases it makes more sense to have them defined in
> +the Containerfile used to create the image.  For example, a Clang-only compiler
> +toolchain image may have ``LLVM=1`` defined.
> +
> +The local environment file is more useful for user-specific variables added
> +during development.  It is passed as-is to the container runtime so its format
> +may vary.  Typically, it will look like the output of ``env``.  For example::
> +
> +  INSTALL_MOD_STRIP=1
> +  SOME_RANDOM_TEXT=One upon a time
> +
> +Please also note that ``make`` options can still be passed on the command line,
> +so while this can't be done since the first argument needs to be the
> +executable::
> +
> +  scripts/container -i tuxmake/korg-clang LLVM=1 make
> +
> +this will work::
> +
> +  scripts/container -i tuxmake/korg-clang make LLVM=1

First of all: Thanks for all that work!


I probably have just read it over: I have to prefix the
'tuxmake/korg-clang' by 'docker.io/'.  Is that a problem of my system
configuration (Debian forky, no special podman config)?


> +
> +
> +User IDs
> +========
> +
> +This is an area where the behaviour will vary slightly depending on the
> +container runtime.  The goal is to run commands as the user invoking the tool.
> +With Podman, a namespace is created to map the current user id to a different
> +one in the container (1000 by default).  With Docker, while this is also
> +possible with recent versions it requires a special feature to be enabled in
> +the daemon so it's not used here for simplicity.  Instead, the container is run
> +with the current user id directly.  In both cases, this will provide the same
> +file permissions for the kernel source tree mounted as a volume.  The only
> +difference is that when using Docker without a namespace, the user id may not
> +be the same as the default one set in the image.
> +
> +Say, we're using an image which sets up a default user with id 1000 and the
> +current user calling the ``container`` tool has id 1234.  The kernel source
> +tree was checked out by this same user so the files belong to user 1234.  With
> +Podman, the container will be running as user id 1000 with a mapping to id 1234
> +so that the files from the mounted volume appear to belong to id 1000 inside
> +the container.  With Docker and no namespace, the container will be running
> +with user id 1234 which can access the files in the volume but not in the user
> +1000 home directory.  This shouldn't be an issue when running commands only in
> +the kernel tree but it is worth highlighting here as it might matter for
> +special corner cases.

I tested a tiny bit with podman as runtime backend.  If I leave out the
'-r podman' podman's docker emulation is in effect and fails with:

    $ scripts/container -i docker.io/tuxmake/korg-clang -- make LLVM=1 -j8 olddefconfig
    Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
    mkdir: cannot create directory '.tmp_15': Permission denied
    mkdir: cannot create directory '.tmp_19': Permission denied
    mkdir: cannot create directory '.tmp_22': Permission denied
    mkdir: cannot create directory '.tmp_25': Permission denied
    mkdir: cannot create directory '.tmp_28': Permission denied
    mkdir: cannot create directory '.tmp_31': Permission denied
      HOSTCC  scripts/basic/fixdep
    error: error opening 'scripts/basic/.fixdep.d': Permission denied
    1 error generated.
    make[2]: *** [scripts/Makefile.host:114: scripts/basic/fixdep] Error 1
    make[1]: *** [/src/Makefile:655: scripts_basic] Error 2
    make: *** [Makefile:248: __sub-make] Error 2
    [exit code 2]

But with '-r podman' it works like a charm.

Would it make sense to switch the default runtime to podman to
prevent non-functional podman-docker emulation?  (Or is this just a
problem on my machine?)

-- 
Nicolas

Hi Nicolas,

On 20/01/2026 2:53 pm, Nicolas Schier wrote:
>> +User IDs
>> +========
>> +
>> +This is an area where the behaviour will vary slightly depending on the
>> +container runtime.  The goal is to run commands as the user invoking the tool.
>> +With Podman, a namespace is created to map the current user id to a different
>> +one in the container (1000 by default).  With Docker, while this is also
>> +possible with recent versions it requires a special feature to be enabled in
>> +the daemon so it's not used here for simplicity.  Instead, the container is run
>> +with the current user id directly.  In both cases, this will provide the same
>> +file permissions for the kernel source tree mounted as a volume.  The only
>> +difference is that when using Docker without a namespace, the user id may not
>> +be the same as the default one set in the image.
>> +
>> +Say, we're using an image which sets up a default user with id 1000 and the
>> +current user calling the ``container`` tool has id 1234.  The kernel source
>> +tree was checked out by this same user so the files belong to user 1234.  With
>> +Podman, the container will be running as user id 1000 with a mapping to id 1234
>> +so that the files from the mounted volume appear to belong to id 1000 inside
>> +the container.  With Docker and no namespace, the container will be running
>> +with user id 1234 which can access the files in the volume but not in the user
>> +1000 home directory.  This shouldn't be an issue when running commands only in
>> +the kernel tree but it is worth highlighting here as it might matter for
>> +special corner cases.
> I tested a tiny bit with podman as runtime backend.  If I leave out the
> '-r podman' podman's docker emulation is in effect and fails with:
> 
>      $ scripts/container -i docker.io/tuxmake/korg-clang -- make LLVM=1 -j8 olddefconfig
>      Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
>      mkdir: cannot create directory '.tmp_15': Permission denied
>      mkdir: cannot create directory '.tmp_19': Permission denied
>      mkdir: cannot create directory '.tmp_22': Permission denied
>      mkdir: cannot create directory '.tmp_25': Permission denied
>      mkdir: cannot create directory '.tmp_28': Permission denied
>      mkdir: cannot create directory '.tmp_31': Permission denied
>        HOSTCC  scripts/basic/fixdep
>      error: error opening 'scripts/basic/.fixdep.d': Permission denied
>      1 error generated.
>      make[2]: *** [scripts/Makefile.host:114: scripts/basic/fixdep] Error 1
>      make[1]: *** [/src/Makefile:655: scripts_basic] Error 2
>      make: *** [Makefile:248: __sub-make] Error 2
>      [exit code 2]
> 
> But with '-r podman' it works like a charm.
> 
> Would it make sense to switch the default runtime to podman to
> prevent non-functional podman-docker emulation?  (Or is this just a
> problem on my machine?)

Yes, I just had a quick look as I'm not familiar with the setup to
run Docker commands on top of the Podman backend.  So I'll swap the
order like Nathan suggested so that Podman takes priority over Docker
and add a note to the docs.  It's on the list of improvements and
I'll work on a proper fix once the initial version of the tool has
landed, assuming this is not a blocking issue.

Thanks for trying it out and reporting this use case.

Cheers,
Guillaume

On Tue, Jan 20, 2026 at 02:53:33PM +0100, Nicolas Schier wrote:
> I probably have just read it over: I have to prefix the
> 'tuxmake/korg-clang' by 'docker.io/'.  Is that a problem of my system
> configuration (Debian forky, no special podman config)?

Some distributions ship registries.conf [1] to allow unqualified image
names but I do not think Debian does. Personally, I use the full name
regardless but it should be easy to create it for commands such as these
to work. I use:

unqualified-search-registries = ['docker.io', 'ghcr.io', 'quay.io']

[1]: https://podman.io/docs/installation#registriesconf

> I tested a tiny bit with podman as runtime backend.  If I leave out the
> '-r podman' podman's docker emulation is in effect and fails with:
> 
>     $ scripts/container -i docker.io/tuxmake/korg-clang -- make LLVM=1 -j8 olddefconfig
>     Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
>     mkdir: cannot create directory '.tmp_15': Permission denied
>     mkdir: cannot create directory '.tmp_19': Permission denied
>     mkdir: cannot create directory '.tmp_22': Permission denied
>     mkdir: cannot create directory '.tmp_25': Permission denied
>     mkdir: cannot create directory '.tmp_28': Permission denied
>     mkdir: cannot create directory '.tmp_31': Permission denied
>       HOSTCC  scripts/basic/fixdep
>     error: error opening 'scripts/basic/.fixdep.d': Permission denied
>     1 error generated.
>     make[2]: *** [scripts/Makefile.host:114: scripts/basic/fixdep] Error 1
>     make[1]: *** [/src/Makefile:655: scripts_basic] Error 2
>     make: *** [Makefile:248: __sub-make] Error 2
>     [exit code 2]
> 
> But with '-r podman' it works like a charm.
> 
> Would it make sense to switch the default runtime to podman to
> prevent non-functional podman-docker emulation?  (Or is this just a
> problem on my machine?)

Yeah, I think it would be better to prefer podman over docker if both
existed on the system. Something like this should do that?

diff --git a/scripts/container b/scripts/container
index dbe92630f05b..50c4ae851001 100755
--- a/scripts/container
+++ b/scripts/container
@@ -105,7 +105,7 @@ class PodmanRuntime(CommonRuntime):
 class Runtimes:
     """List of all supported runtimes"""
 
-    runtimes = [DockerRuntime, PodmanRuntime]
+    runtimes = [PodmanRuntime, DockerRuntime]
 
     @classmethod
     def get_names(cls):

On 20/01/2026 7:35 pm, Nathan Chancellor wrote:
> On Tue, Jan 20, 2026 at 02:53:33PM +0100, Nicolas Schier wrote:
>> I probably have just read it over: I have to prefix the
>> 'tuxmake/korg-clang' by 'docker.io/'.  Is that a problem of my system
>> configuration (Debian forky, no special podman config)?
> 
> Some distributions ship registries.conf [1] to allow unqualified image
> names but I do not think Debian does. Personally, I use the full name
> regardless but it should be easy to create it for commands such as these
> to work. I use:
> 
> unqualified-search-registries = ['docker.io', 'ghcr.io', 'quay.io']
> 
> [1]: https://podman.io/docs/installation#registriesconf

And this is not directly related to the scripts/container tool as it
just passes the image name as-is.  Maybe the example in the docs
should explicitly use docker.io/ though.

>> I tested a tiny bit with podman as runtime backend.  If I leave out the
>> '-r podman' podman's docker emulation is in effect and fails with:
>>
>>      $ scripts/container -i docker.io/tuxmake/korg-clang -- make LLVM=1 -j8 olddefconfig
>>      Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
>>      mkdir: cannot create directory '.tmp_15': Permission denied
>>      mkdir: cannot create directory '.tmp_19': Permission denied
>>      mkdir: cannot create directory '.tmp_22': Permission denied
>>      mkdir: cannot create directory '.tmp_25': Permission denied
>>      mkdir: cannot create directory '.tmp_28': Permission denied
>>      mkdir: cannot create directory '.tmp_31': Permission denied
>>        HOSTCC  scripts/basic/fixdep
>>      error: error opening 'scripts/basic/.fixdep.d': Permission denied
>>      1 error generated.
>>      make[2]: *** [scripts/Makefile.host:114: scripts/basic/fixdep] Error 1
>>      make[1]: *** [/src/Makefile:655: scripts_basic] Error 2
>>      make: *** [Makefile:248: __sub-make] Error 2
>>      [exit code 2]
>>
>> But with '-r podman' it works like a charm.
>>
>> Would it make sense to switch the default runtime to podman to
>> prevent non-functional podman-docker emulation?  (Or is this just a
>> problem on my machine?)
> 
> Yeah, I think it would be better to prefer podman over docker if both
> existed on the system. Something like this should do that?
> 
> diff --git a/scripts/container b/scripts/container
> index dbe92630f05b..50c4ae851001 100755
> --- a/scripts/container
> +++ b/scripts/container
> @@ -105,7 +105,7 @@ class PodmanRuntime(CommonRuntime):
>   class Runtimes:
>       """List of all supported runtimes"""
>   
> -    runtimes = [DockerRuntime, PodmanRuntime]
> +    runtimes = [PodmanRuntime, DockerRuntime]
>   
>       @classmethod
>       def get_names(cls):

Yes this should do the trick, although the help message and docs
would need to be updated too.

A better way still would be to make it able to distinguish between
actual Docker and docker-compatible Podman (e.g. if it's just a
symlink) so it's not just down to luck.  This may be added to the
list of potential improvements.

Feel free to make these tweaks now, or we might wait a bit to see if
others have more feedback with further changes and I can send a v4.

Cheers,
Guillaume

On Wed, Jan 21, 2026 at 10:55:53AM +0100, Guillaume Tucker wrote:
> Feel free to make these tweaks now, or we might wait a bit to see if
> others have more feedback with further changes and I can send a v4.

How about this? Send a v4 with:

1. An initial MAINTAINERS entry addition in patch 1 for
   scripts/container like I suggested earlier and scripts/container
   explicitly added to the KERNEL BUILD section so that Nicolas and I
   are included for handling patches.

2. Add the Documentation to the aforementioned MAINTAINERS entry as part
   of patch 2.

3. Either encorporate my suggested change for preferring podman over
   docker with the appropriate changes elsewhere inte the patch set like
   you mentioned or explore checking for the docker alias explicitly.
   Entirely up to you timewise, as long as it results in Nicolas's
   environment working, since I don't think that will be too uncommon.

4. Encorporate any other feedback that you feel is appropriate at this
   stage (if there is any low hanging fruit).

Then we can apply it so that folks can start using it in -next for
testing and validation. After that, you can start thinking of things you
would want to work on for future merge windows from the list you already
started, as I know how that goes when working on a new tool :)

Cheers,
Nathan

Hi Nathan,

On 22/01/2026 05:55, Nathan Chancellor wrote:
> On Wed, Jan 21, 2026 at 10:55:53AM +0100, Guillaume Tucker wrote:
>> Feel free to make these tweaks now, or we might wait a bit to see if
>> others have more feedback with further changes and I can send a v4.
> 
> How about this? Send a v4 with:
> 
> 1. An initial MAINTAINERS entry addition in patch 1 for
>    scripts/container like I suggested earlier and scripts/container
>    explicitly added to the KERNEL BUILD section so that Nicolas and I
>    are included for handling patches.
> 
> 2. Add the Documentation to the aforementioned MAINTAINERS entry as part
>    of patch 2.
> 
> 3. Either encorporate my suggested change for preferring podman over
>    docker with the appropriate changes elsewhere inte the patch set like
>    you mentioned or explore checking for the docker alias explicitly.
>    Entirely up to you timewise, as long as it results in Nicolas's
>    environment working, since I don't think that will be too uncommon.
> 
> 4. Encorporate any other feedback that you feel is appropriate at this
>    stage (if there is any low hanging fruit).

Sounds great, I just sent a v4 as described above.  I've kept any
extra features out for now to avoid introducing new issues and added
a workaround for out-of-tree builds in the docs.  Hopefully this will
solve Nicolas' use cases and work for others too.

> Then we can apply it so that folks can start using it in -next for
> testing and validation. After that, you can start thinking of things you
> would want to work on for future merge windows from the list you already
> started, as I know how that goes when working on a new tool :)

Thanks again for all the reviews, it'll be good to see what people
make of it!  Meanwhile I'll keep working on further improvements,
starting with the limitations mentioned in the docs.

Cheers,
Guillaume

Actually sending to Nicolas now :) sorry for the noise!

https://lore.kernel.org/linux-kbuild/20260120183550.GD2749368@ax162/

On Tue, Jan 20, 2026 at 11:35:50AM -0700, Nathan Chancellor wrote:
> On Tue, Jan 20, 2026 at 02:53:33PM +0100, Nicolas Schier wrote:
> > I probably have just read it over: I have to prefix the
> > 'tuxmake/korg-clang' by 'docker.io/'.  Is that a problem of my system
> > configuration (Debian forky, no special podman config)?
> 
> Some distributions ship registries.conf [1] to allow unqualified image
> names but I do not think Debian does. Personally, I use the full name
> regardless but it should be easy to create it for commands such as these
> to work. I use:
> 
> unqualified-search-registries = ['docker.io', 'ghcr.io', 'quay.io']
> 
> [1]: https://podman.io/docs/installation#registriesconf
> 
> > I tested a tiny bit with podman as runtime backend.  If I leave out the
> > '-r podman' podman's docker emulation is in effect and fails with:
> > 
> >     $ scripts/container -i docker.io/tuxmake/korg-clang -- make LLVM=1 -j8 olddefconfig
> >     Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
> >     mkdir: cannot create directory '.tmp_15': Permission denied
> >     mkdir: cannot create directory '.tmp_19': Permission denied
> >     mkdir: cannot create directory '.tmp_22': Permission denied
> >     mkdir: cannot create directory '.tmp_25': Permission denied
> >     mkdir: cannot create directory '.tmp_28': Permission denied
> >     mkdir: cannot create directory '.tmp_31': Permission denied
> >       HOSTCC  scripts/basic/fixdep
> >     error: error opening 'scripts/basic/.fixdep.d': Permission denied
> >     1 error generated.
> >     make[2]: *** [scripts/Makefile.host:114: scripts/basic/fixdep] Error 1
> >     make[1]: *** [/src/Makefile:655: scripts_basic] Error 2
> >     make: *** [Makefile:248: __sub-make] Error 2
> >     [exit code 2]
> > 
> > But with '-r podman' it works like a charm.
> > 
> > Would it make sense to switch the default runtime to podman to
> > prevent non-functional podman-docker emulation?  (Or is this just a
> > problem on my machine?)
> 
> Yeah, I think it would be better to prefer podman over docker if both
> existed on the system. Something like this should do that?
> 
> diff --git a/scripts/container b/scripts/container
> index dbe92630f05b..50c4ae851001 100755
> --- a/scripts/container
> +++ b/scripts/container
> @@ -105,7 +105,7 @@ class PodmanRuntime(CommonRuntime):
>  class Runtimes:
>      """List of all supported runtimes"""
>  
> -    runtimes = [DockerRuntime, PodmanRuntime]
> +    runtimes = [PodmanRuntime, DockerRuntime]
>  
>      @classmethod
>      def get_names(cls):
>