* Re: [PATCH v3 0/2] scripts: introduce containerized builds
From: Nathan Chancellor @ 2026-01-20 18:04 UTC (permalink / raw)
To: Nicolas Schier
Cc: Miguel Ojeda, David Gow, Onur Özkan, Arnd Bergmann,
linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm
In-Reply-To: <aW-JJ5DT-LRSZkdF@derry.ads.avm.de>
On Tue, Jan 20, 2026 at 02:54:47PM +0100, Nicolas Schier wrote:
> Out-of-source builds do not work on my system with podman. If this is
> expected, I think it would be great to mention that somewhere in the
> documentation.
Yeah, that is expected for this revision of the script, I brought that
up in a previous review:
https://lore.kernel.org/20251219194748.GA1404325@ax162/
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page
From: Nathan Chancellor @ 2026-01-20 18:35 UTC (permalink / raw)
To: Guillaume Tucker, Miguel Ojeda, David Gow, Onur Özkan,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <aW-I3fNqp_7X0oeg@derry.ads.avm.de>
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):
^ permalink raw reply related
* Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page
From: Nathan Chancellor @ 2026-01-20 18:39 UTC (permalink / raw)
To: Nicolas Schier
Cc: Guillaume Tucker, Miguel Ojeda, David Gow, Onur Özkan,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <20260120183550.GD2749368@ax162>
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):
>
^ permalink raw reply
* Re: [PATCH] [v6] Documentation: Provide guidelines for tool-generated content
From: Jonathan Corbet @ 2026-01-20 21:56 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: Dave Hansen, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, Paul E . McKenney, Simon Glass, Lee Jones,
Lorenzo Stoakes, NeilBrown, Theodore Ts'o, Sasha Levin,
Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260119200418.89541-1-dave.hansen@linux.intel.com>
Dave Hansen <dave.hansen@linux.intel.com> writes:
> In the last few years, the capabilities of coding tools have exploded.
> As those capabilities have expanded, contributors and maintainers have
> more and more questions about how and when to apply those
> capabilities.
>
> Add new Documentation to guide contributors on how to best use kernel
> development tools, new and old.
>
> Note, though, there are fundamentally no new or unique rules in this
> new document. It clarifies expectations that the kernel community has
> had for many years. For example, researchers are already asked to
> disclose the tools they use to find issues by
> Documentation/process/researcher-guidelines.rst. This new document
> just reiterates existing best practices for development tooling.
>
> In short: Please show your work and make sure your contribution is
> easy to review.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
OK, it seems this is ready, so I've just applied it, thanks.
jon
^ permalink raw reply
* Re: [PATCH] doc: kgdb: Add description about rodata=off kernel parameter
From: Jonathan Corbet @ 2026-01-20 21:57 UTC (permalink / raw)
To: Daniel Thompson, junan
Cc: jason.wessel, dianders, workflows, linux-doc, linux-kernel,
Will Deacon
In-Reply-To: <87tswhlkkz.fsf@trenco.lwn.net>
Jonathan Corbet <corbet@lwn.net> writes:
> Daniel Thompson <danielt@kernel.org> writes:
>
>> On Fri, Jan 16, 2026 at 01:03:13PM +0800, junan wrote:
>>> STRICT_KERNEL_RWX can not be turned off throught menuconfig on some
>>> architectures, pass "rodata=off" to the kernel in this case.
>>>
>>> Tested with qemu on arm64.
>>>
>>> Signed-off-by: junan <junan76@163.com>
>>> Suggested-by: Will Deacon <will@kernel.org>
>>
>> Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
>>
>> Jonathan: do you want to take this or should I take it via the kgdb
>> tree?
>
> I'm fine either way; I'll pick it up shortly unless you say you've
> already done so.
...and I have just done that, thanks.
jon
^ permalink raw reply
* Re: [PATCH 0/9] docs: Fix kernel-doc -Werror and moves it to tools/docs
From: Jonathan Corbet @ 2026-01-20 22:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, Alex Shi, Carlos Bilbao, David Airlie,
Federico Vaga, Hu Haowen, Jani Nikula, Joonas Lahtinen,
Mauro Carvalho Chehab, Nathan Chancellor, Nicolas Schier,
Rodrigo Vivi, Simona Vetter, Tvrtko Ursulin, Yanteng Si,
dri-devel, intel-gfx, linux-doc, linux-kbuild, linux-kernel,
workflows, Thomas Weißschuh, Andy Shevchenko, Avadhut Naik,
Chenguang Zhao, David Disseldorp, Dongliang Mu, Gang Yan,
Kees Cook, Masahiro Yamada, Miguel Ojeda, Randy Dunlap,
Shuah Khan, Steven Rostedt, Tamir Duberstein, Vincent Mailhol,
WangYuli
In-Reply-To: <cover.1768823489.git.mchehab+huawei@kernel.org>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> Hi Jon,
>
> After a restful weekend and revisiting both yours and my series,
> I'm opting to send a patch series merging both into one:
>
> - The first 4 patches are from my series (no changes since v5):
> https://lore.kernel.org/linux-doc/cover.1768642102.git.mchehab+huawei@kernel.org/T/#m81211c0ff38bbaa82b8b0b6606f242ccc0c2a9ac
>
> - It follows by the 2 patches from your renaming series:
> https://lore.kernel.org/linux-doc/20260119111745.4694546b@foz.lan/T/#m51099c31a99dccccdb4d17cbaadc818e9e4df8c4
>
> with the fix I proposed for kernel-doc to find its libraries
>
> I added 3 patches afterwards:
>
> - patch 5: move possible return values from docstring to helper message;
> - patch 6: improve MsgFormatter description;
> - patch 7: moves kerneldoc_bin from conf.py to the sphinx/kerneldoc.py
> (this is now just a debugging message - no need to pick it from env)
>
> IMO, this series is ready to be merged.
Patch 7 adds a new warning:
WARNING: unknown config value 'kerneldoc_bin' in override, ignoring
It needs to be taken out of sphinx-build-wrapper; I've appended the
following patch to the series to deal with it. I think I'll go ahead
and tack on a patch putting in the scripts/kernel-doc symlink, then I
guess it's ready to go.
Thanks,
jon
From 4a3efd128f7da996b677151790d043ec44a00561 Mon Sep 17 00:00:00 2001
From: Jonathan Corbet <corbet@lwn.net>
Date: Tue, 20 Jan 2026 15:50:38 -0700
Subject: [PATCH] docs: sphinx-build-wrapper: stop setting kerneldoc_bin for
Sphinx
Now that the Sphinx build does not use the kerneldoc_bin configuration
variable, we shouldn't try to set it in the build wrapper or we get a nifty
warning:
WARNING: unknown config value 'kerneldoc_bin' in override, ignoring
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
tools/docs/sphinx-build-wrapper | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/docs/sphinx-build-wrapper b/tools/docs/sphinx-build-wrapper
index cb2a5005e633..9f1ae1485f84 100755
--- a/tools/docs/sphinx-build-wrapper
+++ b/tools/docs/sphinx-build-wrapper
@@ -750,7 +750,6 @@ class SphinxBuilder:
build_args = args + [
"-d", doctree_dir,
- "-D", f"kerneldoc_bin={kerneldoc}",
"-D", f"version={self.kernelversion}",
"-D", f"release={self.kernelrelease}",
"-D", f"kerneldoc_srctree={self.srctree}",
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 0/9] docs: Fix kernel-doc -Werror and moves it to tools/docs
From: Mauro Carvalho Chehab @ 2026-01-20 23:00 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Alex Shi, Carlos Bilbao, David Airlie, Federico Vaga, Hu Haowen,
Jani Nikula, Joonas Lahtinen, Mauro Carvalho Chehab,
Nathan Chancellor, Nicolas Schier, Rodrigo Vivi, Simona Vetter,
Tvrtko Ursulin, Yanteng Si, dri-devel, intel-gfx, linux-doc,
linux-kbuild, linux-kernel, workflows, Thomas Weißschuh,
Andy Shevchenko, Avadhut Naik, Chenguang Zhao, David Disseldorp,
Dongliang Mu, Gang Yan, Kees Cook, Masahiro Yamada, Miguel Ojeda,
Randy Dunlap, Shuah Khan, Steven Rostedt, Tamir Duberstein,
Vincent Mailhol, WangYuli
In-Reply-To: <87wm1bhozz.fsf@trenco.lwn.net>
Hi Jon,
On Tue, 20 Jan 2026 15:56:48 -0700
Jonathan Corbet <corbet@lwn.net> wrote:
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
>
> > Hi Jon,
> >
> > After a restful weekend and revisiting both yours and my series,
> > I'm opting to send a patch series merging both into one:
> >
> > - The first 4 patches are from my series (no changes since v5):
> > https://lore.kernel.org/linux-doc/cover.1768642102.git.mchehab+huawei@kernel.org/T/#m81211c0ff38bbaa82b8b0b6606f242ccc0c2a9ac
> >
> > - It follows by the 2 patches from your renaming series:
> > https://lore.kernel.org/linux-doc/20260119111745.4694546b@foz.lan/T/#m51099c31a99dccccdb4d17cbaadc818e9e4df8c4
> >
> > with the fix I proposed for kernel-doc to find its libraries
> >
> > I added 3 patches afterwards:
> >
> > - patch 5: move possible return values from docstring to helper message;
> > - patch 6: improve MsgFormatter description;
> > - patch 7: moves kerneldoc_bin from conf.py to the sphinx/kerneldoc.py
> > (this is now just a debugging message - no need to pick it from env)
> >
> > IMO, this series is ready to be merged.
>
> Patch 7 adds a new warning:
>
> WARNING: unknown config value 'kerneldoc_bin' in override, ignoring
>
> It needs to be taken out of sphinx-build-wrapper; I've appended the
> following patch to the series to deal with it.
True, thanks for checking it!
> I think I'll go ahead
> and tack on a patch putting in the scripts/kernel-doc symlink, then I
> guess it's ready to go.
Go ahead. Yeah, I think that, with such changes, this series is
ready to go.
>
> Thanks,
>
> jon
>
> From 4a3efd128f7da996b677151790d043ec44a00561 Mon Sep 17 00:00:00 2001
> From: Jonathan Corbet <corbet@lwn.net>
> Date: Tue, 20 Jan 2026 15:50:38 -0700
> Subject: [PATCH] docs: sphinx-build-wrapper: stop setting kerneldoc_bin for
> Sphinx
>
> Now that the Sphinx build does not use the kerneldoc_bin configuration
> variable, we shouldn't try to set it in the build wrapper or we get a nifty
> warning:
>
> WARNING: unknown config value 'kerneldoc_bin' in override, ignoring
>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
> tools/docs/sphinx-build-wrapper | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/docs/sphinx-build-wrapper b/tools/docs/sphinx-build-wrapper
> index cb2a5005e633..9f1ae1485f84 100755
> --- a/tools/docs/sphinx-build-wrapper
> +++ b/tools/docs/sphinx-build-wrapper
> @@ -750,7 +750,6 @@ class SphinxBuilder:
>
> build_args = args + [
> "-d", doctree_dir,
> - "-D", f"kerneldoc_bin={kerneldoc}",
> "-D", f"version={self.kernelversion}",
> "-D", f"release={self.kernelrelease}",
> "-D", f"kerneldoc_srctree={self.srctree}",
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2026-01-21 9:55 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <20260120183550.GD2749368@ax162>
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
^ permalink raw reply
* Re: [PATCH v3 0/2] scripts: introduce containerized builds
From: Guillaume Tucker @ 2026-01-21 10:13 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan,
Nicolas Schier
Cc: Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <aW-JJ5DT-LRSZkdF@derry.ads.avm.de>
Hi Nicolas,
On 20/01/2026 2:54 pm, Nicolas Schier wrote:
> Out-of-source builds do not work on my system with podman. If this is
> expected, I think it would be great to mention that somewhere in the
> documentation.
Yes, as discussed with Nathan. So here's the list of potential
improvements gathered so far:
* automatically pick Podman first, Docker second
* explicitly mention docker.io registry in examples
* mention TuxMake available images more explicitly in the docs
* mention that out-of-tree builds aren't supported yet
* distinguish true Docker from Docker-compatible Podman
* add support for out-of-tree output build directory
* add option for mounting source tree from arbitrary path
(needed for nested containers e.g. Docker-in-Docker)
* detect when Docker has namespace support enabled and document
* add user config file with default images and runtime etc.
Then beyond that we could consider other container runtimes such as
containerd, lxc, runc or whatever works in practice.
> Nevertheless, thanks a lot! I expect me to use that a lot in the
> future!
>
> For the whole patch set:
> Tested-by: Nicolas Schier<nsc@kernel.org>
> Acked-by: Nicolas Schier<nsc@kernel.org>
Thank you! Let's hope others will find it useful too.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page
From: Nathan Chancellor @ 2026-01-22 4:55 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Miguel Ojeda, David Gow, Onur Özkan, Arnd Bergmann,
linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm
In-Reply-To: <e96a6e71-80b3-4556-a4eb-fd242e0f5713@gtucker.io>
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
^ permalink raw reply
* Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2026-01-22 10:13 UTC (permalink / raw)
To: Nicolas Schier
Cc: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <aW-I3fNqp_7X0oeg@derry.ads.avm.de>
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
^ permalink raw reply
* [PATCH] doc: development-process: add notice on testing
From: Dmitry Antipov @ 2026-01-22 11:15 UTC (permalink / raw)
To: Andy Shevchenko, Jonathan Corbet; +Cc: workflows, linux-doc, Dmitry Antipov
Add testing notice to "Before creating patches" section.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
---
Documentation/process/5.Posting.rst | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index 9999bcbdccc9..0271a4dc525e 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -40,7 +40,12 @@ sending patches to the development community. These include:
- Test the code to the extent that you can. Make use of the kernel's
debugging tools, ensure that the kernel will build with all reasonable
combinations of configuration options, use cross-compilers to build for
- different architectures, etc.
+ different architectures, etc. Add tests, likely using an existing
+ testing frameworks like KUnit, and include them as a separate member
+ of your series (see the next section on what about the series is).
+ Note that this may be mandatory when affecting some subsystems. For
+ example, library functions (resides under lib/) are extensively used
+ almost everywhere and expected to be tested appropriately.
- Make sure your code is compliant with the kernel coding style
guidelines.
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] doc: development-process: add notice on testing
From: Andy Shevchenko @ 2026-01-22 11:56 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Jonathan Corbet, workflows, linux-doc
In-Reply-To: <20260122111525.1112145-1-dmantipov@yandex.ru>
On Thu, Jan 22, 2026 at 02:15:25PM +0300, Dmitry Antipov wrote:
> Add testing notice to "Before creating patches" section.
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Thanks!
I may confirm that lib/ is indeed a hotspot for treewide users and breaking
anything in lib/ almost always break at least a couple of users sometimes in
unexpected places. That's why the test cases are mandatory for a new feature
that will be reside in lib/.
> --- a/Documentation/process/5.Posting.rst
> +++ b/Documentation/process/5.Posting.rst
> - Test the code to the extent that you can. Make use of the kernel's
> debugging tools, ensure that the kernel will build with all reasonable
> combinations of configuration options, use cross-compilers to build for
> - different architectures, etc.
> + different architectures, etc. Add tests, likely using an existing
> + testing frameworks like KUnit, and include them as a separate member
> + of your series (see the next section on what about the series is).
> + Note that this may be mandatory when affecting some subsystems. For
> + example, library functions (resides under lib/) are extensively used
> + almost everywhere and expected to be tested appropriately.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v4 0/2] scripts: introduce containerized builds
From: Guillaume Tucker @ 2026-01-22 14:06 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Onur Özkan
Cc: Guillaume Tucker, Arnd Bergmann, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm
This proposal emerged from discussions over email and after a talk at
Plumbers 2024:
https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
The aim is to facilitate reproducing builds for CI bots as well as
developers using containers. Here's an illustrative example with a
kernel.org toolchain in a Docker image from tuxmake:
$ scripts/container -i docker.io/tuxmake/korg-clang-21 make LLVM=1 defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
[...]
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
This patch series also includes a documentation page with all the
relevant details and further examples about how to use the tool.
To go one step further, I'm in the process of preparing reference
container images with kernel.org toolchains and no third-party
dependencies other than the base Debian distro. See this thread for
more details and options to host them in an upstream way:
https://lore.kernel.org/all/cc737636-2a43-4a97-975e-4725733f7ee4@gtucker.io/
Say, to run KUnit using the latest kernel.org GCC toolchain:
scripts/container --shell \
-i registry.gitlab.com/gtucker/korg-containers/gcc:kunit -- \
tools/testing/kunit/kunit.py \
run \
--arch=x86_64 \
--cross_compile=x86_64-linux-
---
Changes in v4:
- Add entries to MAINTAINERS for the new script and docs
- Give priority to Podman over Docker when no -r option given
- Update help message and docs regarding Podman priority
- Add note and workaround for out-of-tree builds in the docs
- Mention TuxMake prebuilt images more explicitly in the docs
Changes in v3:
- Refactor common code for Docker and Podman
- Add docs.kernel.org URL in help message
- Use pathlib Python package
- Handle signals in parent process by default
- Add --shell option to use an interactive shell
- Tweak debug messages in verbose mode
- Specify Python 3.10 as minimum version in the docs
- Provide an example env file in the docs
- Update docs regarding interactive shell usage
Changes in v2:
- Drop default image but make -i option required
- Look for Docker and Podman if no runtime specified
- Catch SIGINT from user to abort container with Docker
- Explicitly name each container with a UUID
- Update documentation accordingly
---
Guillaume Tucker (2):
scripts: add tool to run containerized builds
Documentation: dev-tools: add container.rst page
Documentation/dev-tools/container.rst | 227 ++++++++++++++++++++++++++
Documentation/dev-tools/index.rst | 1 +
MAINTAINERS | 7 +
scripts/container | 199 ++++++++++++++++++++++
4 files changed, 434 insertions(+)
create mode 100644 Documentation/dev-tools/container.rst
create mode 100755 scripts/container
--
2.47.3
^ permalink raw reply
* [PATCH v4 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2026-01-22 14:06 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Onur Özkan
Cc: Guillaume Tucker, Arnd Bergmann, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm
In-Reply-To: <cover.1769090419.git.gtucker@gtucker.io>
Add a 'scripts/container' tool written in Python to run any command in
the source tree from within a container. This can typically be used
to call 'make' with a compiler toolchain image to run reproducible
builds but any arbitrary command can be run too. Only Docker and
Podman are supported in this initial version.
Add a new entry to MAINTAINERS accordingly.
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nicolas Schier <nsc@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: David Gow <davidgow@google.com>
Cc: "Onur Özkan" <work@onurozkan.dev>
Link: https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
---
MAINTAINERS | 6 ++
scripts/container | 199 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 205 insertions(+)
create mode 100755 scripts/container
diff --git a/MAINTAINERS b/MAINTAINERS
index da9dbc1a4019..affd55ff05e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6384,6 +6384,11 @@ S: Supported
F: drivers/video/console/
F: include/linux/console*
+CONTAINER BUILD SCRIPT
+M: Guillaume Tucker <gtucker@gtucker.io>
+S: Maintained
+F: scripts/container
+
CONTEXT TRACKING
M: Frederic Weisbecker <frederic@kernel.org>
M: "Paul E. McKenney" <paulmck@kernel.org>
@@ -13676,6 +13681,7 @@ F: scripts/Makefile*
F: scripts/bash-completion/
F: scripts/basic/
F: scripts/clang-tools/
+F: scripts/container
F: scripts/dummy-tools/
F: scripts/include/
F: scripts/mk*
diff --git a/scripts/container b/scripts/container
new file mode 100755
index 000000000000..09663eccb8d3
--- /dev/null
+++ b/scripts/container
@@ -0,0 +1,199 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2025 Guillaume Tucker
+
+"""Containerized builds"""
+
+import abc
+import argparse
+import logging
+import os
+import pathlib
+import shutil
+import subprocess
+import sys
+import uuid
+
+
+class ContainerRuntime(abc.ABC):
+ """Base class for a container runtime implementation"""
+
+ name = None # Property defined in each implementation class
+
+ def __init__(self, args, logger):
+ self._uid = args.uid or os.getuid()
+ self._gid = args.gid or args.uid or os.getgid()
+ self._env_file = args.env_file
+ self._shell = args.shell
+ self._logger = logger
+
+ @classmethod
+ def is_present(cls):
+ """Determine whether the runtime is present on the system"""
+ return shutil.which(cls.name) is not None
+
+ @abc.abstractmethod
+ def _do_run(self, image, cmd, container_name):
+ """Runtime-specific handler to run a command in a container"""
+
+ @abc.abstractmethod
+ def _do_abort(self, container_name):
+ """Runtime-specific handler to abort a running container"""
+
+ def run(self, image, cmd):
+ """Run a command in a runtime container"""
+ container_name = str(uuid.uuid4())
+ self._logger.debug("container: %s", container_name)
+ try:
+ return self._do_run(image, cmd, container_name)
+ except KeyboardInterrupt:
+ self._logger.error("user aborted")
+ self._do_abort(container_name)
+ return 1
+
+
+class CommonRuntime(ContainerRuntime):
+ """Common logic for Docker and Podman"""
+
+ def _do_run(self, image, cmd, container_name):
+ cmdline = [self.name, 'run']
+ cmdline += self._get_opts(container_name)
+ cmdline.append(image)
+ cmdline += cmd
+ self._logger.debug('command: %s', ' '.join(cmdline))
+ return subprocess.call(cmdline)
+
+ def _get_opts(self, container_name):
+ opts = [
+ '--name', container_name,
+ '--rm',
+ '--volume', f'{pathlib.Path.cwd()}:/src',
+ '--workdir', '/src',
+ ]
+ if self._env_file:
+ opts += ['--env-file', self._env_file]
+ if self._shell:
+ opts += ['--interactive', '--tty']
+ return opts
+
+ def _do_abort(self, container_name):
+ subprocess.call([self.name, 'kill', container_name])
+
+
+class DockerRuntime(CommonRuntime):
+ """Run a command in a Docker container"""
+
+ name = 'docker'
+
+ def _get_opts(self, container_name):
+ return super()._get_opts(container_name) + [
+ '--user', f'{self._uid}:{self._gid}'
+ ]
+
+
+class PodmanRuntime(CommonRuntime):
+ """Run a command in a Podman container"""
+
+ name = 'podman'
+
+ def _get_opts(self, container_name):
+ return super()._get_opts(container_name) + [
+ '--userns', f'keep-id:uid={self._uid},gid={self._gid}',
+ ]
+
+
+class Runtimes:
+ """List of all supported runtimes"""
+
+ runtimes = [PodmanRuntime, DockerRuntime]
+
+ @classmethod
+ def get_names(cls):
+ """Get a list of all the runtime names"""
+ return list(runtime.name for runtime in cls.runtimes)
+
+ @classmethod
+ def get(cls, name):
+ """Get a single runtime class matching the given name"""
+ for runtime in cls.runtimes:
+ if runtime.name == name:
+ if not runtime.is_present():
+ raise ValueError(f"runtime not found: {name}")
+ return runtime
+ raise ValueError(f"unknown runtime: {runtime}")
+
+ @classmethod
+ def find(cls):
+ """Find the first runtime present on the system"""
+ for runtime in cls.runtimes:
+ if runtime.is_present():
+ return runtime
+ raise ValueError("no runtime found")
+
+
+def _get_logger(verbose):
+ """Set up a logger with the appropriate level"""
+ logger = logging.getLogger('container')
+ handler = logging.StreamHandler()
+ handler.setFormatter(logging.Formatter(
+ fmt='[container {levelname}] {message}', style='{'
+ ))
+ logger.addHandler(handler)
+ logger.setLevel(logging.DEBUG if verbose is True else logging.INFO)
+ return logger
+
+
+def main(args):
+ """Main entry point for the container tool"""
+ logger = _get_logger(args.verbose)
+ try:
+ cls = Runtimes.get(args.runtime) if args.runtime else Runtimes.find()
+ except ValueError as ex:
+ logger.error(ex)
+ return 1
+ logger.debug("runtime: %s", cls.name)
+ logger.debug("image: %s", args.image)
+ return cls(args, logger).run(args.image, args.cmd)
+
+
+if __name__ == '__main__':
+ parser = argparse.ArgumentParser(
+ 'container',
+ description="See the documentation for more details: "
+ "https://docs.kernel.org/dev-tools/container.html"
+ )
+ parser.add_argument(
+ '-e', '--env-file',
+ help="Path to an environment file to load in the container."
+ )
+ parser.add_argument(
+ '-g', '--gid',
+ help="Group ID to use inside the container."
+ )
+ parser.add_argument(
+ '-i', '--image', required=True,
+ help="Container image name."
+ )
+ parser.add_argument(
+ '-r', '--runtime', choices=Runtimes.get_names(),
+ help="Container runtime name. If not specified, the first one found "
+ "on the system will be used i.e. Podman if present, otherwise Docker."
+ )
+ parser.add_argument(
+ '-s', '--shell', action='store_true',
+ help="Run the container in an interactive shell."
+ )
+ parser.add_argument(
+ '-u', '--uid',
+ help="User ID to use inside the container. If the -g option is not "
+ "specified, the user ID will also be set as the group ID."
+ )
+ parser.add_argument(
+ '-v', '--verbose', action='store_true',
+ help="Enable verbose output."
+ )
+ parser.add_argument(
+ 'cmd', nargs='+',
+ help="Command to run in the container"
+ )
+ sys.exit(main(parser.parse_args(sys.argv[1:])))
--
2.47.3
^ permalink raw reply related
* [PATCH v4 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2026-01-22 14:07 UTC (permalink / raw)
To: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Onur Özkan
Cc: Guillaume Tucker, Arnd Bergmann, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm
In-Reply-To: <cover.1769090419.git.gtucker@gtucker.io>
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.
Update MAINTAINERS accordingly with a reference to the added file.
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nicolas Schier <nsc@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 | 227 ++++++++++++++++++++++++++
Documentation/dev-tools/index.rst | 1 +
MAINTAINERS | 1 +
3 files changed, 229 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..452415b64662
--- /dev/null
+++ b/Documentation/dev-tools/container.rst
@@ -0,0 +1,227 @@
+.. 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. Podman if present, otherwise Docker.
+
+``-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 while giving priority to Podman. 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.
+
+.. note::
+
+ Out-of-tree builds are not fully supported yet. The ``O=`` option can
+ however already be used with a relative path inside the source tree to keep
+ separate build outputs. A workaround to build outside the tree is to use
+ ``mount --bind``, see the examples section further down.
+
+
+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 docker.io/tuxmake/korg-clang LLVM=1 make # won't work
+
+this will work::
+
+ scripts/container -i docker.io/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.
+
+.. note::
+
+ Podman's `Docker compatibility
+ <https://podman-desktop.io/docs/migrating-from-docker/managing-docker-compatibility>`__
+ mode to run ``docker`` commands on top of a Podman backend is more complex
+ and not fully supported yet. As such, Podman will take priority if both
+ runtimes are available on the system.
+
+
+Examples
+========
+
+The TuxMake project provides a variety of prebuilt container images available
+on `Docker Hub <https://hub.docker.com/u/tuxmake>`__. Here's the shortest
+example to build a kernel using a TuxMake Clang image::
+
+ scripts/container -i docker.io/tuxmake/korg-clang -- make LLVM=1 defconfig
+ scripts/container -i docker.io/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 docker.io/tuxmake/korg-clang make mrproper
+
+To run ``checkpatch.pl`` in a ``patches`` directory with a generic Perl image::
+
+ scripts/container -i perl:slim-trixie scripts/checkpatch.pl patches/*
+
+As an alternative to the TuxMake images, 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)
+
+For an out-of-tree build, a trick is to bind-mount the destination directory to
+a relative path inside the source tree::
+
+ mkdir -p $HOME/tmp/my-kernel-build
+ mkdir -p build
+ sudo mount --bind $HOME/tmp/my-kernel-build build
+ scripts/container -i kernel.org/gcc -- make mrproper
+ scripts/container -i kernel.org/gcc -- make O=build defconfig
+ scripts/container -i kernel.org/gcc -- make O=build -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
diff --git a/MAINTAINERS b/MAINTAINERS
index affd55ff05e0..4e82dba3bd25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6387,6 +6387,7 @@ F: include/linux/console*
CONTAINER BUILD SCRIPT
M: Guillaume Tucker <gtucker@gtucker.io>
S: Maintained
+F: Documentation/dev-tools/container.rst
F: scripts/container
CONTEXT TRACKING
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 0/2] scripts: introduce containerized builds
From: Guillaume Tucker @ 2026-01-22 14:12 UTC (permalink / raw)
To: Nicolas Schier
Cc: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <aW-JJ5DT-LRSZkdF@derry.ads.avm.de>
Hi Nicolas,
On 20/01/2026 14:54, Nicolas Schier wrote:
> Out-of-source builds do not work on my system with podman. If this is
> expected, I think it would be great to mention that somewhere in the
> documentation.
The v4 now mentions this and also includes a trick using bind-mount:
mkdir -p $HOME/tmp/my-kernel-build
mkdir -p build
sudo mount --bind $HOME/tmp/my-kernel-build build
scripts/container -i kernel.org/gcc -- make mrproper
scripts/container -i kernel.org/gcc -- make O=build defconfig
scripts/container -i kernel.org/gcc -- make O=build -j$(nproc)
Would this work for your use-case? Directory names are entirely
arbitrary. It's not ideal but might be good enough as a workaround
until this gets properly supported by the tool in a future version.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2026-01-22 14:25 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Miguel Ojeda, David Gow, Onur Özkan, Arnd Bergmann,
linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm
In-Reply-To: <20260122045534.GA3770486@ax162>
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
^ permalink raw reply
* Re: [PATCH v4 1/2] scripts: add tool to run containerized builds
From: Onur Özkan @ 2026-01-22 14:29 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <9b8da20157e409e8fa3134d2101678779e157256.1769090419.git.gtucker@gtucker.io>
Hi Guillaume,
Just 2 notes from my end.
On Thu, 22 Jan 2026 15:06:59 +0100
Guillaume Tucker <gtucker@gtucker.io> wrote:
> Add a 'scripts/container' tool written in Python to run any command in
> the source tree from within a container. This can typically be used
> to call 'make' with a compiler toolchain image to run reproducible
> builds but any arbitrary command can be run too. Only Docker and
> Podman are supported in this initial version.
>
> Add a new entry to MAINTAINERS accordingly.
>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nicolas Schier <nsc@kernel.org>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Cc: David Gow <davidgow@google.com>
> Cc: "Onur Özkan" <work@onurozkan.dev>
> Link:
> https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io> ---
> MAINTAINERS | 6 ++
> scripts/container | 199
> ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 205
> insertions(+) create mode 100755 scripts/container
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index da9dbc1a4019..affd55ff05e0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6384,6 +6384,11 @@ S: Supported
> F: drivers/video/console/
> F: include/linux/console*
>
> +CONTAINER BUILD SCRIPT
> +M: Guillaume Tucker <gtucker@gtucker.io>
> +S: Maintained
> +F: scripts/container
> +
> CONTEXT TRACKING
> M: Frederic Weisbecker <frederic@kernel.org>
> M: "Paul E. McKenney" <paulmck@kernel.org>
> @@ -13676,6 +13681,7 @@ F: scripts/Makefile*
> F: scripts/bash-completion/
> F: scripts/basic/
> F: scripts/clang-tools/
> +F: scripts/container
> F: scripts/dummy-tools/
> F: scripts/include/
> F: scripts/mk*
> diff --git a/scripts/container b/scripts/container
> new file mode 100755
> index 000000000000..09663eccb8d3
> --- /dev/null
> +++ b/scripts/container
> @@ -0,0 +1,199 @@
> +#!/usr/bin/env python3
> +# SPDX-License-Identifier: GPL-2.0-only
> +# Copyright (C) 2025 Guillaume Tucker
> +
> +"""Containerized builds"""
> +
> +import abc
> +import argparse
> +import logging
> +import os
> +import pathlib
> +import shutil
> +import subprocess
> +import sys
> +import uuid
> +
> +
> +class ContainerRuntime(abc.ABC):
> + """Base class for a container runtime implementation"""
> +
> + name = None # Property defined in each implementation class
> +
> + def __init__(self, args, logger):
> + self._uid = args.uid or os.getuid()
> + self._gid = args.gid or args.uid or os.getgid()
> + self._env_file = args.env_file
> + self._shell = args.shell
> + self._logger = logger
> +
> + @classmethod
> + def is_present(cls):
> + """Determine whether the runtime is present on the system"""
> + return shutil.which(cls.name) is not None
> +
> + @abc.abstractmethod
> + def _do_run(self, image, cmd, container_name):
> + """Runtime-specific handler to run a command in a
> container""" +
> + @abc.abstractmethod
> + def _do_abort(self, container_name):
> + """Runtime-specific handler to abort a running container"""
> +
> + def run(self, image, cmd):
> + """Run a command in a runtime container"""
> + container_name = str(uuid.uuid4())
> + self._logger.debug("container: %s", container_name)
> + try:
> + return self._do_run(image, cmd, container_name)
> + except KeyboardInterrupt:
> + self._logger.error("user aborted")
> + self._do_abort(container_name)
> + return 1
> +
> +
> +class CommonRuntime(ContainerRuntime):
> + """Common logic for Docker and Podman"""
> +
> + def _do_run(self, image, cmd, container_name):
> + cmdline = [self.name, 'run']
> + cmdline += self._get_opts(container_name)
> + cmdline.append(image)
> + cmdline += cmd
> + self._logger.debug('command: %s', ' '.join(cmdline))
> + return subprocess.call(cmdline)
> +
> + def _get_opts(self, container_name):
> + opts = [
> + '--name', container_name,
> + '--rm',
> + '--volume', f'{pathlib.Path.cwd()}:/src',
> + '--workdir', '/src',
> + ]
> + if self._env_file:
> + opts += ['--env-file', self._env_file]
> + if self._shell:
> + opts += ['--interactive', '--tty']
> + return opts
> +
> + def _do_abort(self, container_name):
> + subprocess.call([self.name, 'kill', container_name])
> +
> +
> +class DockerRuntime(CommonRuntime):
> + """Run a command in a Docker container"""
> +
> + name = 'docker'
> +
> + def _get_opts(self, container_name):
> + return super()._get_opts(container_name) + [
> + '--user', f'{self._uid}:{self._gid}'
> + ]
> +
> +
> +class PodmanRuntime(CommonRuntime):
> + """Run a command in a Podman container"""
> +
> + name = 'podman'
> +
> + def _get_opts(self, container_name):
> + return super()._get_opts(container_name) + [
> + '--userns', f'keep-id:uid={self._uid},gid={self._gid}',
> + ]
> +
> +
> +class Runtimes:
> + """List of all supported runtimes"""
> +
> + runtimes = [PodmanRuntime, DockerRuntime]
> +
> + @classmethod
> + def get_names(cls):
> + """Get a list of all the runtime names"""
> + return list(runtime.name for runtime in cls.runtimes)
> +
> + @classmethod
> + def get(cls, name):
> + """Get a single runtime class matching the given name"""
> + for runtime in cls.runtimes:
> + if runtime.name == name:
> + if not runtime.is_present():
> + raise ValueError(f"runtime not found: {name}")
> + return runtime
> + raise ValueError(f"unknown runtime: {runtime}")
> +
I think you meant to use "{name}" not "{runtime}" inside ValueError.
> + @classmethod
> + def find(cls):
> + """Find the first runtime present on the system"""
> + for runtime in cls.runtimes:
> + if runtime.is_present():
> + return runtime
> + raise ValueError("no runtime found")
> +
nit: We could extend the error message like: "Couldn't find any runtime.
Use -r <runtime> to specify one manually". What do you think?
> +
> +def _get_logger(verbose):
> + """Set up a logger with the appropriate level"""
> + logger = logging.getLogger('container')
> + handler = logging.StreamHandler()
> + handler.setFormatter(logging.Formatter(
> + fmt='[container {levelname}] {message}', style='{'
> + ))
> + logger.addHandler(handler)
> + logger.setLevel(logging.DEBUG if verbose is True else
> logging.INFO)
> + return logger
> +
> +
> +def main(args):
> + """Main entry point for the container tool"""
> + logger = _get_logger(args.verbose)
> + try:
> + cls = Runtimes.get(args.runtime) if args.runtime else
> Runtimes.find()
> + except ValueError as ex:
> + logger.error(ex)
> + return 1
> + logger.debug("runtime: %s", cls.name)
> + logger.debug("image: %s", args.image)
> + return cls(args, logger).run(args.image, args.cmd)
> +
> +
> +if __name__ == '__main__':
> + parser = argparse.ArgumentParser(
> + 'container',
> + description="See the documentation for more details: "
> + "https://docs.kernel.org/dev-tools/container.html"
> + )
> + parser.add_argument(
> + '-e', '--env-file',
> + help="Path to an environment file to load in the container."
> + )
> + parser.add_argument(
> + '-g', '--gid',
> + help="Group ID to use inside the container."
> + )
> + parser.add_argument(
> + '-i', '--image', required=True,
> + help="Container image name."
> + )
> + parser.add_argument(
> + '-r', '--runtime', choices=Runtimes.get_names(),
> + help="Container runtime name. If not specified, the first
> one found "
> + "on the system will be used i.e. Podman if present,
> otherwise Docker."
> + )
> + parser.add_argument(
> + '-s', '--shell', action='store_true',
> + help="Run the container in an interactive shell."
> + )
> + parser.add_argument(
> + '-u', '--uid',
> + help="User ID to use inside the container. If the -g option
> is not "
> + "specified, the user ID will also be set as the group ID."
> + )
> + parser.add_argument(
> + '-v', '--verbose', action='store_true',
> + help="Enable verbose output."
> + )
> + parser.add_argument(
> + 'cmd', nargs='+',
> + help="Command to run in the container"
> + )
> + sys.exit(main(parser.parse_args(sys.argv[1:])))
The rest LGTM.
Regards,
Onur
^ permalink raw reply
* Re: [PATCH v4 2/2] Documentation: dev-tools: add container.rst page
From: Onur Özkan @ 2026-01-22 14:22 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <af886533cc5cbdd6ef1d909793b79a1ad42c74ca.1769090419.git.gtucker@gtucker.io>
On Thu, 22 Jan 2026 15:07:00 +0100
Guillaume Tucker <gtucker@gtucker.io> 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.
>
> Update MAINTAINERS accordingly with a reference to the added file.
>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nicolas Schier <nsc@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 | 227
> ++++++++++++++++++++++++++ Documentation/dev-tools/index.rst |
> 1 + MAINTAINERS | 1 +
> 3 files changed, 229 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..452415b64662
> --- /dev/null
> +++ b/Documentation/dev-tools/container.rst
> @@ -0,0 +1,227 @@
> +.. 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. Podman if present, otherwise Docker.
> +
> +``-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 while
> giving priority to Podman. 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.
> +
> +.. note::
> +
> + Out-of-tree builds are not fully supported yet. The ``O=``
> option can
> + however already be used with a relative path inside the source
> tree to keep
> + separate build outputs. A workaround to build outside the tree
> is to use
> + ``mount --bind``, see the examples section further down.
> +
> +
> +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 docker.io/tuxmake/korg-clang LLVM=1 make #
> won't work +
> +this will work::
> +
> + scripts/container -i docker.io/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. +
> +.. note::
> +
> + Podman's `Docker compatibility
> +
> <https://podman-desktop.io/docs/migrating-from-docker/managing-docker-compatibility>`__
> + mode to run ``docker`` commands on top of a Podman backend is
> more complex
> + and not fully supported yet. As such, Podman will take priority
> if both
> + runtimes are available on the system.
> +
> +
> +Examples
> +========
> +
> +The TuxMake project provides a variety of prebuilt container images
> available +on `Docker Hub <https://hub.docker.com/u/tuxmake>`__.
> Here's the shortest +example to build a kernel using a TuxMake Clang
> image:: +
> + scripts/container -i docker.io/tuxmake/korg-clang -- make LLVM=1
> defconfig
> + scripts/container -i docker.io/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 docker.io/tuxmake/korg-clang make mrproper
> +
> +To run ``checkpatch.pl`` in a ``patches`` directory with a generic
> Perl image:: +
> + scripts/container -i perl:slim-trixie scripts/checkpatch.pl
> patches/* +
> +As an alternative to the TuxMake images, 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)
> +
> +For an out-of-tree build, a trick is to bind-mount the destination
> directory to +a relative path inside the source tree::
> +
> + mkdir -p $HOME/tmp/my-kernel-build
> + mkdir -p build
> + sudo mount --bind $HOME/tmp/my-kernel-build build
> + scripts/container -i kernel.org/gcc -- make mrproper
> + scripts/container -i kernel.org/gcc -- make O=build defconfig
> + scripts/container -i kernel.org/gcc -- make O=build -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
> diff --git a/MAINTAINERS b/MAINTAINERS
> index affd55ff05e0..4e82dba3bd25 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6387,6 +6387,7 @@ F: include/linux/console*
> CONTAINER BUILD SCRIPT
> M: Guillaume Tucker <gtucker@gtucker.io>
> S: Maintained
> +F: Documentation/dev-tools/container.rst
> F: scripts/container
>
> CONTEXT TRACKING
This looks great.
Reviewed-by: Onur Özkan <work@onurozkan.dev>
^ permalink raw reply
* Re: [PATCH v4 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2026-01-22 14:59 UTC (permalink / raw)
To: Onur Özkan
Cc: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <20260122172928.1d922490@nimda>
Hi Onur,
On 22/01/2026 15:29, Onur Özkan wrote:
> Hi Guillaume,
>
> Just 2 notes from my end.
>
> On Thu, 22 Jan 2026 15:06:59 +0100
> Guillaume Tucker <gtucker@gtucker.io> wrote:
>
>> Add a 'scripts/container' tool written in Python to run any command in
>> the source tree from within a container. This can typically be used
>> to call 'make' with a compiler toolchain image to run reproducible
>> builds but any arbitrary command can be run too. Only Docker and
>> Podman are supported in this initial version.
>>
>> Add a new entry to MAINTAINERS accordingly.
>>
>> Cc: Nathan Chancellor <nathan@kernel.org>
>> Cc: Nicolas Schier <nsc@kernel.org>
>> Cc: Miguel Ojeda <ojeda@kernel.org>
>> Cc: David Gow <davidgow@google.com>
>> Cc: "Onur Özkan" <work@onurozkan.dev>
>> Link:
>> https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
>> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io> ---
>> MAINTAINERS | 6 ++
>> scripts/container | 199
>> ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 205
>> insertions(+) create mode 100755 scripts/container
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index da9dbc1a4019..affd55ff05e0 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6384,6 +6384,11 @@ S: Supported
>> F: drivers/video/console/
>> F: include/linux/console*
>>
>> +CONTAINER BUILD SCRIPT
>> +M: Guillaume Tucker <gtucker@gtucker.io>
>> +S: Maintained
>> +F: scripts/container
>> +
>> CONTEXT TRACKING
>> M: Frederic Weisbecker <frederic@kernel.org>
>> M: "Paul E. McKenney" <paulmck@kernel.org>
>> @@ -13676,6 +13681,7 @@ F: scripts/Makefile*
>> F: scripts/bash-completion/
>> F: scripts/basic/
>> F: scripts/clang-tools/
>> +F: scripts/container
>> F: scripts/dummy-tools/
>> F: scripts/include/
>> F: scripts/mk*
>> diff --git a/scripts/container b/scripts/container
>> new file mode 100755
>> index 000000000000..09663eccb8d3
>> --- /dev/null
>> +++ b/scripts/container
>> @@ -0,0 +1,199 @@
>> +#!/usr/bin/env python3
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +# Copyright (C) 2025 Guillaume Tucker
>> +
>> +"""Containerized builds"""
>> +
>> +import abc
>> +import argparse
>> +import logging
>> +import os
>> +import pathlib
>> +import shutil
>> +import subprocess
>> +import sys
>> +import uuid
>> +
>> +
>> +class ContainerRuntime(abc.ABC):
>> + """Base class for a container runtime implementation"""
>> +
>> + name = None # Property defined in each implementation class
>> +
>> + def __init__(self, args, logger):
>> + self._uid = args.uid or os.getuid()
>> + self._gid = args.gid or args.uid or os.getgid()
>> + self._env_file = args.env_file
>> + self._shell = args.shell
>> + self._logger = logger
>> +
>> + @classmethod
>> + def is_present(cls):
>> + """Determine whether the runtime is present on the system"""
>> + return shutil.which(cls.name) is not None
>> +
>> + @abc.abstractmethod
>> + def _do_run(self, image, cmd, container_name):
>> + """Runtime-specific handler to run a command in a
>> container""" +
>> + @abc.abstractmethod
>> + def _do_abort(self, container_name):
>> + """Runtime-specific handler to abort a running container"""
>> +
>> + def run(self, image, cmd):
>> + """Run a command in a runtime container"""
>> + container_name = str(uuid.uuid4())
>> + self._logger.debug("container: %s", container_name)
>> + try:
>> + return self._do_run(image, cmd, container_name)
>> + except KeyboardInterrupt:
>> + self._logger.error("user aborted")
>> + self._do_abort(container_name)
>> + return 1
>> +
>> +
>> +class CommonRuntime(ContainerRuntime):
>> + """Common logic for Docker and Podman"""
>> +
>> + def _do_run(self, image, cmd, container_name):
>> + cmdline = [self.name, 'run']
>> + cmdline += self._get_opts(container_name)
>> + cmdline.append(image)
>> + cmdline += cmd
>> + self._logger.debug('command: %s', ' '.join(cmdline))
>> + return subprocess.call(cmdline)
>> +
>> + def _get_opts(self, container_name):
>> + opts = [
>> + '--name', container_name,
>> + '--rm',
>> + '--volume', f'{pathlib.Path.cwd()}:/src',
>> + '--workdir', '/src',
>> + ]
>> + if self._env_file:
>> + opts += ['--env-file', self._env_file]
>> + if self._shell:
>> + opts += ['--interactive', '--tty']
>> + return opts
>> +
>> + def _do_abort(self, container_name):
>> + subprocess.call([self.name, 'kill', container_name])
>> +
>> +
>> +class DockerRuntime(CommonRuntime):
>> + """Run a command in a Docker container"""
>> +
>> + name = 'docker'
>> +
>> + def _get_opts(self, container_name):
>> + return super()._get_opts(container_name) + [
>> + '--user', f'{self._uid}:{self._gid}'
>> + ]
>> +
>> +
>> +class PodmanRuntime(CommonRuntime):
>> + """Run a command in a Podman container"""
>> +
>> + name = 'podman'
>> +
>> + def _get_opts(self, container_name):
>> + return super()._get_opts(container_name) + [
>> + '--userns', f'keep-id:uid={self._uid},gid={self._gid}',
>> + ]
>> +
>> +
>> +class Runtimes:
>> + """List of all supported runtimes"""
>> +
>> + runtimes = [PodmanRuntime, DockerRuntime]
>> +
>> + @classmethod
>> + def get_names(cls):
>> + """Get a list of all the runtime names"""
>> + return list(runtime.name for runtime in cls.runtimes)
>> +
>> + @classmethod
>> + def get(cls, name):
>> + """Get a single runtime class matching the given name"""
>> + for runtime in cls.runtimes:
>> + if runtime.name == name:
>> + if not runtime.is_present():
>> + raise ValueError(f"runtime not found: {name}")
>> + return runtime
>> + raise ValueError(f"unknown runtime: {runtime}")
>> +
>
> I think you meant to use "{name}" not "{runtime}" inside ValueError.
Ah yes, sorry. The parser already checks that the runtime name is in
the list so I've never hit this error. We would probably need some
unit tests at some point.
So yes this fixes the issue, which can be reproduced with a small
hack in the script to relax the -r option checks:
--- a/scripts/container
+++ b/scripts/container
@@ -120,7 +120,7 @@ class Runtimes:
if not runtime.is_present():
raise ValueError(f"runtime not found: {name}")
return runtime
- raise ValueError(f"unknown runtime: {runtime}")
+ raise ValueError(f"unknown runtime: {name}")
@classmethod
def find(cls):
Nathan, would you be OK with folding this in or should I send a v5?
>> + @classmethod
>> + def find(cls):
>> + """Find the first runtime present on the system"""
>> + for runtime in cls.runtimes:
>> + if runtime.is_present():
>> + return runtime
>> + raise ValueError("no runtime found")
>> +
>
> nit: We could extend the error message like: "Couldn't find any runtime.
> Use -r <runtime> to specify one manually". What do you think?
I'm all for improving the user experience. It's good to keep the
implementation logic separate from the command line interface though.
Maybe this is something I could improve in a follow-up? There are a
few other potential things to rework in this area; a more detailed
error could be logged in main().
>> +
>> +def _get_logger(verbose):
>> + """Set up a logger with the appropriate level"""
>> + logger = logging.getLogger('container')
>> + handler = logging.StreamHandler()
>> + handler.setFormatter(logging.Formatter(
>> + fmt='[container {levelname}] {message}', style='{'
>> + ))
>> + logger.addHandler(handler)
>> + logger.setLevel(logging.DEBUG if verbose is True else
>> logging.INFO)
>> + return logger
>> +
>> +
>> +def main(args):
>> + """Main entry point for the container tool"""
>> + logger = _get_logger(args.verbose)
>> + try:
>> + cls = Runtimes.get(args.runtime) if args.runtime else
>> Runtimes.find()
>> + except ValueError as ex:
>> + logger.error(ex)
>> + return 1
>> + logger.debug("runtime: %s", cls.name)
>> + logger.debug("image: %s", args.image)
>> + return cls(args, logger).run(args.image, args.cmd)
>> +
>> +
>> +if __name__ == '__main__':
>> + parser = argparse.ArgumentParser(
>> + 'container',
>> + description="See the documentation for more details: "
>> + "https://docs.kernel.org/dev-tools/container.html"
>> + )
>> + parser.add_argument(
>> + '-e', '--env-file',
>> + help="Path to an environment file to load in the container."
>> + )
>> + parser.add_argument(
>> + '-g', '--gid',
>> + help="Group ID to use inside the container."
>> + )
>> + parser.add_argument(
>> + '-i', '--image', required=True,
>> + help="Container image name."
>> + )
>> + parser.add_argument(
>> + '-r', '--runtime', choices=Runtimes.get_names(),
>> + help="Container runtime name. If not specified, the first
>> one found "
>> + "on the system will be used i.e. Podman if present,
>> otherwise Docker."
>> + )
>> + parser.add_argument(
>> + '-s', '--shell', action='store_true',
>> + help="Run the container in an interactive shell."
>> + )
>> + parser.add_argument(
>> + '-u', '--uid',
>> + help="User ID to use inside the container. If the -g option
>> is not "
>> + "specified, the user ID will also be set as the group ID."
>> + )
>> + parser.add_argument(
>> + '-v', '--verbose', action='store_true',
>> + help="Enable verbose output."
>> + )
>> + parser.add_argument(
>> + 'cmd', nargs='+',
>> + help="Command to run in the container"
>> + )
>> + sys.exit(main(parser.parse_args(sys.argv[1:])))
>
> The rest LGTM.
Thanks for the reviews.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v4 1/2] scripts: add tool to run containerized builds
From: Onur Özkan @ 2026-01-22 16:39 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Nathan Chancellor, Nicolas Schier, Miguel Ojeda, David Gow,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <611ce02f-2b48-4338-b37f-1df39e02da03@gtucker.io>
On Thu, 22 Jan 2026 15:59:54 +0100
Guillaume Tucker <gtucker@gtucker.io> wrote:
> Hi Onur,
>
> On 22/01/2026 15:29, Onur Özkan wrote:
> > Hi Guillaume,
> >
> > Just 2 notes from my end.
> >
> > On Thu, 22 Jan 2026 15:06:59 +0100
> > Guillaume Tucker <gtucker@gtucker.io> wrote:
> >
> >> Add a 'scripts/container' tool written in Python to run any
> >> command in the source tree from within a container. This can
> >> typically be used to call 'make' with a compiler toolchain image
> >> to run reproducible builds but any arbitrary command can be run
> >> too. Only Docker and Podman are supported in this initial version.
> >>
> >> Add a new entry to MAINTAINERS accordingly.
> >>
> >> Cc: Nathan Chancellor <nathan@kernel.org>
> >> Cc: Nicolas Schier <nsc@kernel.org>
> >> Cc: Miguel Ojeda <ojeda@kernel.org>
> >> Cc: David Gow <davidgow@google.com>
> >> Cc: "Onur Özkan" <work@onurozkan.dev>
> >> Link:
> >> https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
> >> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io> ---
> >> MAINTAINERS | 6 ++
> >> scripts/container | 199
> >> ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 205
> >> insertions(+) create mode 100755 scripts/container
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index da9dbc1a4019..affd55ff05e0 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -6384,6 +6384,11 @@ S: Supported
> >> F: drivers/video/console/
> >> F: include/linux/console*
> >>
> >> +CONTAINER BUILD SCRIPT
> >> +M: Guillaume Tucker <gtucker@gtucker.io>
> >> +S: Maintained
> >> +F: scripts/container
> >> +
> >> CONTEXT TRACKING
> >> M: Frederic Weisbecker <frederic@kernel.org>
> >> M: "Paul E. McKenney" <paulmck@kernel.org>
> >> @@ -13676,6 +13681,7 @@ F: scripts/Makefile*
> >> F: scripts/bash-completion/
> >> F: scripts/basic/
> >> F: scripts/clang-tools/
> >> +F: scripts/container
> >> F: scripts/dummy-tools/
> >> F: scripts/include/
> >> F: scripts/mk*
> >> diff --git a/scripts/container b/scripts/container
> >> new file mode 100755
> >> index 000000000000..09663eccb8d3
> >> --- /dev/null
> >> +++ b/scripts/container
> >> @@ -0,0 +1,199 @@
> >> +#!/usr/bin/env python3
> >> +# SPDX-License-Identifier: GPL-2.0-only
> >> +# Copyright (C) 2025 Guillaume Tucker
> >> +
> >> +"""Containerized builds"""
> >> +
> >> +import abc
> >> +import argparse
> >> +import logging
> >> +import os
> >> +import pathlib
> >> +import shutil
> >> +import subprocess
> >> +import sys
> >> +import uuid
> >> +
> >> +
> >> +class ContainerRuntime(abc.ABC):
> >> + """Base class for a container runtime implementation"""
> >> +
> >> + name = None # Property defined in each implementation class
> >> +
> >> + def __init__(self, args, logger):
> >> + self._uid = args.uid or os.getuid()
> >> + self._gid = args.gid or args.uid or os.getgid()
> >> + self._env_file = args.env_file
> >> + self._shell = args.shell
> >> + self._logger = logger
> >> +
> >> + @classmethod
> >> + def is_present(cls):
> >> + """Determine whether the runtime is present on the
> >> system"""
> >> + return shutil.which(cls.name) is not None
> >> +
> >> + @abc.abstractmethod
> >> + def _do_run(self, image, cmd, container_name):
> >> + """Runtime-specific handler to run a command in a
> >> container""" +
> >> + @abc.abstractmethod
> >> + def _do_abort(self, container_name):
> >> + """Runtime-specific handler to abort a running
> >> container""" +
> >> + def run(self, image, cmd):
> >> + """Run a command in a runtime container"""
> >> + container_name = str(uuid.uuid4())
> >> + self._logger.debug("container: %s", container_name)
> >> + try:
> >> + return self._do_run(image, cmd, container_name)
> >> + except KeyboardInterrupt:
> >> + self._logger.error("user aborted")
> >> + self._do_abort(container_name)
> >> + return 1
> >> +
> >> +
> >> +class CommonRuntime(ContainerRuntime):
> >> + """Common logic for Docker and Podman"""
> >> +
> >> + def _do_run(self, image, cmd, container_name):
> >> + cmdline = [self.name, 'run']
> >> + cmdline += self._get_opts(container_name)
> >> + cmdline.append(image)
> >> + cmdline += cmd
> >> + self._logger.debug('command: %s', ' '.join(cmdline))
> >> + return subprocess.call(cmdline)
> >> +
> >> + def _get_opts(self, container_name):
> >> + opts = [
> >> + '--name', container_name,
> >> + '--rm',
> >> + '--volume', f'{pathlib.Path.cwd()}:/src',
> >> + '--workdir', '/src',
> >> + ]
> >> + if self._env_file:
> >> + opts += ['--env-file', self._env_file]
> >> + if self._shell:
> >> + opts += ['--interactive', '--tty']
> >> + return opts
> >> +
> >> + def _do_abort(self, container_name):
> >> + subprocess.call([self.name, 'kill', container_name])
> >> +
> >> +
> >> +class DockerRuntime(CommonRuntime):
> >> + """Run a command in a Docker container"""
> >> +
> >> + name = 'docker'
> >> +
> >> + def _get_opts(self, container_name):
> >> + return super()._get_opts(container_name) + [
> >> + '--user', f'{self._uid}:{self._gid}'
> >> + ]
> >> +
> >> +
> >> +class PodmanRuntime(CommonRuntime):
> >> + """Run a command in a Podman container"""
> >> +
> >> + name = 'podman'
> >> +
> >> + def _get_opts(self, container_name):
> >> + return super()._get_opts(container_name) + [
> >> + '--userns',
> >> f'keep-id:uid={self._uid},gid={self._gid}',
> >> + ]
> >> +
> >> +
> >> +class Runtimes:
> >> + """List of all supported runtimes"""
> >> +
> >> + runtimes = [PodmanRuntime, DockerRuntime]
> >> +
> >> + @classmethod
> >> + def get_names(cls):
> >> + """Get a list of all the runtime names"""
> >> + return list(runtime.name for runtime in cls.runtimes)
> >> +
> >> + @classmethod
> >> + def get(cls, name):
> >> + """Get a single runtime class matching the given name"""
> >> + for runtime in cls.runtimes:
> >> + if runtime.name == name:
> >> + if not runtime.is_present():
> >> + raise ValueError(f"runtime not found: {name}")
> >> + return runtime
> >> + raise ValueError(f"unknown runtime: {runtime}")
> >> +
> >
> > I think you meant to use "{name}" not "{runtime}" inside ValueError.
>
> Ah yes, sorry. The parser already checks that the runtime name is in
> the list so I've never hit this error. We would probably need some
> unit tests at some point.
>
> So yes this fixes the issue, which can be reproduced with a small
> hack in the script to relax the -r option checks:
>
> --- a/scripts/container
> +++ b/scripts/container
> @@ -120,7 +120,7 @@ class Runtimes:
> if not runtime.is_present():
> raise ValueError(f"runtime not found: {name}")
> return runtime
> - raise ValueError(f"unknown runtime: {runtime}")
> + raise ValueError(f"unknown runtime: {name}")
>
> @classmethod
> def find(cls):
>
>
> Nathan, would you be OK with folding this in or should I send a v5?
>
> >> + @classmethod
> >> + def find(cls):
> >> + """Find the first runtime present on the system"""
> >> + for runtime in cls.runtimes:
> >> + if runtime.is_present():
> >> + return runtime
> >> + raise ValueError("no runtime found")
> >> +
> >
> > nit: We could extend the error message like: "Couldn't find any
> > runtime. Use -r <runtime> to specify one manually". What do you
> > think?
>
> I'm all for improving the user experience. It's good to keep the
> implementation logic separate from the command line interface though.
> Maybe this is something I could improve in a follow-up? There are a
> few other potential things to rework in this area; a more detailed
> error could be logged in main().
>
Sure, sounds good to me.
Thanks,
Onur
> >> +
> >> +def _get_logger(verbose):
> >> + """Set up a logger with the appropriate level"""
> >> + logger = logging.getLogger('container')
> >> + handler = logging.StreamHandler()
> >> + handler.setFormatter(logging.Formatter(
> >> + fmt='[container {levelname}] {message}', style='{'
> >> + ))
> >> + logger.addHandler(handler)
> >> + logger.setLevel(logging.DEBUG if verbose is True else
> >> logging.INFO)
> >> + return logger
> >> +
> >> +
> >> +def main(args):
> >> + """Main entry point for the container tool"""
> >> + logger = _get_logger(args.verbose)
> >> + try:
> >> + cls = Runtimes.get(args.runtime) if args.runtime else
> >> Runtimes.find()
> >> + except ValueError as ex:
> >> + logger.error(ex)
> >> + return 1
> >> + logger.debug("runtime: %s", cls.name)
> >> + logger.debug("image: %s", args.image)
> >> + return cls(args, logger).run(args.image, args.cmd)
> >> +
> >> +
> >> +if __name__ == '__main__':
> >> + parser = argparse.ArgumentParser(
> >> + 'container',
> >> + description="See the documentation for more details: "
> >> + "https://docs.kernel.org/dev-tools/container.html"
> >> + )
> >> + parser.add_argument(
> >> + '-e', '--env-file',
> >> + help="Path to an environment file to load in the
> >> container."
> >> + )
> >> + parser.add_argument(
> >> + '-g', '--gid',
> >> + help="Group ID to use inside the container."
> >> + )
> >> + parser.add_argument(
> >> + '-i', '--image', required=True,
> >> + help="Container image name."
> >> + )
> >> + parser.add_argument(
> >> + '-r', '--runtime', choices=Runtimes.get_names(),
> >> + help="Container runtime name. If not specified, the first
> >> one found "
> >> + "on the system will be used i.e. Podman if present,
> >> otherwise Docker."
> >> + )
> >> + parser.add_argument(
> >> + '-s', '--shell', action='store_true',
> >> + help="Run the container in an interactive shell."
> >> + )
> >> + parser.add_argument(
> >> + '-u', '--uid',
> >> + help="User ID to use inside the container. If the -g
> >> option is not "
> >> + "specified, the user ID will also be set as the group ID."
> >> + )
> >> + parser.add_argument(
> >> + '-v', '--verbose', action='store_true',
> >> + help="Enable verbose output."
> >> + )
> >> + parser.add_argument(
> >> + 'cmd', nargs='+',
> >> + help="Command to run in the container"
> >> + )
> >> + sys.exit(main(parser.parse_args(sys.argv[1:])))
> >
> > The rest LGTM.
>
> Thanks for the reviews.
>
> Cheers,
> Guillaume
^ permalink raw reply
* Re: [PATCH] doc: development-process: add notice on testing
From: Randy Dunlap @ 2026-01-22 18:28 UTC (permalink / raw)
To: Dmitry Antipov, Andy Shevchenko, Jonathan Corbet; +Cc: workflows, linux-doc
In-Reply-To: <20260122111525.1112145-1-dmantipov@yandex.ru>
Hi,
On 1/22/26 3:15 AM, Dmitry Antipov wrote:
> Add testing notice to "Before creating patches" section.
>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> Documentation/process/5.Posting.rst | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> index 9999bcbdccc9..0271a4dc525e 100644
> --- a/Documentation/process/5.Posting.rst
> +++ b/Documentation/process/5.Posting.rst
> @@ -40,7 +40,12 @@ sending patches to the development community. These include:
> - Test the code to the extent that you can. Make use of the kernel's
> debugging tools, ensure that the kernel will build with all reasonable
> combinations of configuration options, use cross-compilers to build for
> - different architectures, etc.
> + different architectures, etc. Add tests, likely using an existing
> + testing frameworks like KUnit, and include them as a separate member
framework
> + of your series (see the next section on what about the series is).
(see the next section for more about patch series).
> + Note that this may be mandatory when affecting some subsystems. For
> + example, library functions (resides under lib/) are extensively used
> + almost everywhere and expected to be tested appropriately.
>
> - Make sure your code is compliant with the kernel coding style
> guidelines.
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 1/2] scripts: add tool to run containerized builds
From: Nathan Chancellor @ 2026-01-22 18:49 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Onur Özkan, Nicolas Schier, Miguel Ojeda, David Gow,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <611ce02f-2b48-4338-b37f-1df39e02da03@gtucker.io>
On Thu, Jan 22, 2026 at 03:59:54PM +0100, Guillaume Tucker wrote:
> --- a/scripts/container
> +++ b/scripts/container
> @@ -120,7 +120,7 @@ class Runtimes:
> if not runtime.is_present():
> raise ValueError(f"runtime not found: {name}")
> return runtime
> - raise ValueError(f"unknown runtime: {runtime}")
> + raise ValueError(f"unknown runtime: {name}")
>
> @classmethod
> def find(cls):
>
>
> Nathan, would you be OK with folding this in or should I send a v5?
I can fold that in, thanks.
I will carry forward Nicolas's ack and testing tags from v3, as this
revision is not substantially different from what he looked at and
tested.
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v4 1/2] scripts: add tool to run containerized builds
From: Nicolas Schier @ 2026-01-22 19:57 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Guillaume Tucker, Onur Özkan, Miguel Ojeda, David Gow,
Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <20260122184939.GA3461196@ax162>
On Thu, Jan 22, 2026 at 11:49:39AM -0700, Nathan Chancellor wrote:
> On Thu, Jan 22, 2026 at 03:59:54PM +0100, Guillaume Tucker wrote:
> > --- a/scripts/container
> > +++ b/scripts/container
> > @@ -120,7 +120,7 @@ class Runtimes:
> > if not runtime.is_present():
> > raise ValueError(f"runtime not found: {name}")
> > return runtime
> > - raise ValueError(f"unknown runtime: {runtime}")
> > + raise ValueError(f"unknown runtime: {name}")
> >
> > @classmethod
> > def find(cls):
> >
> >
> > Nathan, would you be OK with folding this in or should I send a v5?
>
> I can fold that in, thanks.
>
> I will carry forward Nicolas's ack and testing tags from v3, as this
> revision is not substantially different from what he looked at and
> tested.
thanks!
Kind regards,
Nicolas
^ permalink raw reply
page: next (older) | 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