* Re: [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Jonathan Corbet @ 2025-12-22 22:01 UTC (permalink / raw)
To: Andi Shyti, Federico Vaga
Cc: linux-doc, linux-kernel, workflows, Andy Shevchenko
In-Reply-To: <klzag46p6mlqqdrogqofancqyjpvs5lmwa4m3tjszcgavdwa6s@nay2uuwpsvlt>
Andi Shyti <andi.shyti@kernel.org> writes:
> Hi Federico,
>
>> >-Il file di intestazione include/linux/kernel.h contiene un certo numero
>> >-di macro che dovreste usare piuttosto che implementarne una qualche variante.
>> >-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
>> >-macro:
>> >+I file header
>>
>> In Italian, the correct name for "header file" is "file di intestazione".
>> Please, don't replace correct Italian with *Itanglese* :)
>
> I absolutely disagree.
>
> If you open any C book, they are called 'header files', except
> for a few Italian technical books with excessively literal
> translations, where even non-translatable terms are translated.
I'm unconvinced about "file di intestazione" based on my own
understanding of the language... but, in a case like this, I will defer
to the creator and maintainer of the translation.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 1/1] docs: Update documentation to avoid mentioning of kernel.h
From: Jonathan Corbet @ 2025-12-22 22:00 UTC (permalink / raw)
To: Andy Shevchenko, Randy Dunlap, Andy Shevchenko,
Dr. David Alan Gilbert, linux-doc, linux-kernel, workflows,
linux-remoteproc
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Dwaipayan Ray, Lukas Bulwahn, Joe Perches, Bjorn Andersson,
Mathieu Poirier
In-Reply-To: <20251126214709.2322314-1-andriy.shevchenko@linux.intel.com>
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> For several years, and still ongoing, the kernel.h is being split
> to smaller and narrow headers to avoid "including everything" approach
> which is bad in many ways. Since that, documentation missed a few
> required updates to align with that work. Do it here.
>
> Note, language translations are left untouched and if anybody willing
> to help, please provide path(es) based on the updated English variant.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> ---
>
> v2: collected tag (Randy), fixed util_macros k-doc (Randy, me), fixed spelling (Randy)
>
> Documentation/core-api/kobject.rst | 2 +-
> Documentation/dev-tools/checkpatch.rst | 2 +-
> Documentation/driver-api/basics.rst | 17 ++++++++++++++++-
> .../driver-api/driver-model/design-patterns.rst | 2 +-
> Documentation/process/coding-style.rst | 10 +++++++---
> Documentation/staging/rpmsg.rst | 7 +++++--
> include/linux/util_macros.h | 2 +-
> 7 files changed, 32 insertions(+), 10 deletions(-)
Applied (finally) thanks.
jon
^ permalink raw reply
* Re: [PATCH v2 1/2] scripts: add tool to run containerized builds
From: Konstantin Ryabitsev @ 2025-12-22 16:12 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Miguel Ojeda, Nathan Chancellor, Miguel Ojeda, David Gow,
Onur Özkan, Arnd Bergmann, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm
In-Reply-To: <09b3bc78-6c55-4d8c-8d09-9f313454dee3@gtucker.io>
On Mon, Dec 22, 2025 at 10:11:25AM +0100, Guillaume Tucker wrote:
> Ah yes, good point. Except right now it's returning HTTP 403...
> Hopefully that's just a temporary technical glitch.
(it was)
-K
^ permalink raw reply
* Re: [PATCH v2 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-22 9:11 UTC (permalink / raw)
To: Miguel Ojeda
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: <CANiq72mtqdR0EU9GM6yu1-Rn0V98ZftUA814eY3ue2YH1xdNHw@mail.gmail.com>
Hi Miguel,
On 22/12/2025 04:30, Miguel Ojeda wrote:
> On Sun, Dec 21, 2025 at 9:19 PM Guillaume Tucker <gtucker@gtucker.io> wrote:
>>
>> Another piece of feedback from your v1 review was to add a link to
>> the documentation. As it's not published yet I just mentioned the
>> section name here in the v2 - but I can anticipate what the final URL
>> will be i.e.:
>>
>> https://www.kernel.org/doc/html/latest/dev-tools/container
>
> A docs.kernel.org URL instead may look better?
Ah yes, good point. Except right now it's returning HTTP 403...
Hopefully that's just a temporary technical glitch.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v2 1/2] scripts: add tool to run containerized builds
From: Miguel Ojeda @ 2025-12-22 3:30 UTC (permalink / raw)
To: Guillaume Tucker
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: <3241bbcb-d9c1-49bd-b8a7-610543dfb454@gtucker.io>
On Sun, Dec 21, 2025 at 9:19 PM Guillaume Tucker <gtucker@gtucker.io> wrote:
>
> Another piece of feedback from your v1 review was to add a link to
> the documentation. As it's not published yet I just mentioned the
> section name here in the v2 - but I can anticipate what the final URL
> will be i.e.:
>
> https://www.kernel.org/doc/html/latest/dev-tools/container
A docs.kernel.org URL instead may look better?
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-21 20:19 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan
Cc: Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <35b951506304b141047812f516fa946a4f1549a1.1766061692.git.gtucker@gtucker.io>
Hi Nathan,
On 18/12/2025 1:49 pm, Guillaume Tucker wrote:
> +if __name__ == '__main__':
> + parser = argparse.ArgumentParser(
> + 'container',
> + description="Containerized builds. See the dev-tools/container "
> + "kernel documentation section for more details."
> + )
Another piece of feedback from your v1 review was to add a link to
the documentation. As it's not published yet I just mentioned the
section name here in the v2 - but I can anticipate what the final URL
will be i.e.:
https://www.kernel.org/doc/html/latest/dev-tools/container
So I'll tweak this as well in the v3 unless anyone suggests
otherwise.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2025-12-21 20:13 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda, David Gow, Onur Özkan
Cc: Arnd Bergmann, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm
In-Reply-To: <ff8da6b9680ef01ee44f6d0cf89e34dd76abb116.1766061692.git.gtucker@gtucker.io>
Hi Nathan,
On 18/12/2025 1:49 pm, Guillaume Tucker 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.
This part of the docs explains why things are a bit different between
Podman and Docker. In both cases, it should "just work" from a user
point of view - just with some special corner cases. Let me know if
you thing the documentation needs to be improved.
I may add a runtime check as a follow-up to detect if namespaces are
enabled in Docker and if so use them, but to get started I wanted to
keep things as simple as possible.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v2 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-21 20:09 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: <20251219212731.GC1407372@ax162>
On 19/12/2025 10:27 pm, Nathan Chancellor wrote:
> On Thu, Dec 18, 2025 at 01:49:52PM +0100, Guillaume Tucker wrote:
> ...
>> + def __init__(self, args, logger):
> Adding something like
>
> self._args = [
> '--rm',
> '--tty',
> '--volume', f'{os.getcwd()}:/src',
> '--workdir', '/src',
> ]
>
> here then adding an __init__() in the subclasses to append the runtime
> specific arguments would allow _do_run() to be moved into
> ContainerRuntime(). Otherwise, this looks pretty good and extensible.
Yes, I left these very similar parts as-is on purpose to make it very
clear what the command line arguments are for each container runtime.
It's a good idea to refactor this though as you mention, and I'll add
a debug log message to print the command line instead.
I'm also anticipating that other runtimes will be quite different,
Podman and Docker just so happen to have many options in common.
Things like runc or containerd are very different beasts so I don't
want to over-generalise. But this is straightforward enough for now.
So I'll rework this a bit in a v3.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-21 20:04 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Miguel Ojeda, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm, Arnd Bergmann
In-Reply-To: <20251219211518.GB1407372@ax162>
Hi Nathan,
On 19/12/2025 10:15 pm, Nathan Chancellor wrote:
> On Fri, Dec 19, 2025 at 12:47:48PM -0700, Nathan Chancellor wrote:
>> Most of these two functions are the same. Maybe they could be abstracted
>> into a simple class so that most of the logic could be shared between
>> the two implementations? That also might simplify main() a bit and make
>> fulfilling David's request a little simpler as well.
>
> Sigh, this is what I get for working through my inbox bottom up since I
> see that you did this in v2 :) looks good, I will give a couple more
> comments there.
Thank you twice for the reviews then :) Yes I'm glad the v2
pre-addressed some of the things you mentioned. I'll reply there too
regarding user id management etc.
In the meantime I also started this thread about container images:
https://lore.kernel.org/all/cc737636-2a43-4a97-975e-4725733f7ee4@gtucker.io/
I believe this will go hand-in-hand with the scripts/container tool,
not with hard dependencies but they will enhance each other.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v2 1/2] scripts: add tool to run containerized builds
From: Nathan Chancellor @ 2025-12-19 21:27 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: <35b951506304b141047812f516fa946a4f1549a1.1766061692.git.gtucker@gtucker.io>
On Thu, Dec 18, 2025 at 01:49:52PM +0100, Guillaume Tucker wrote:
...
> + def __init__(self, args, logger):
Adding something like
self._args = [
'--rm',
'--tty',
'--volume', f'{os.getcwd()}:/src',
'--workdir', '/src',
]
here then adding an __init__() in the subclasses to append the runtime
specific arguments would allow _do_run() to be moved into
ContainerRuntime(). Otherwise, this looks pretty good and extensible.
> + self._uid = args.uid or os.getuid()
> + self._gid = args.gid or args.uid or os.getgid()
> + self._env_file = args.env_file
> + 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 command in 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 DockerRuntime(ContainerRuntime):
> + """Run a command in a Docker container"""
> +
> + name = 'docker'
> +
> + def _do_run(self, image, cmd, container_name):
> + cmdline = [
> + 'docker', 'run',
> + '--name', container_name,
> + '--rm',
> + '--tty',
> + '--volume', f'{os.getcwd()}:/src',
> + '--workdir', '/src',
> + '--user', f'{self._uid}:{self._gid}'
> + ]
> + if self._env_file:
> + cmdline += ['--env-file', self._env_file]
> + cmdline.append(image)
> + cmdline += cmd
> + return subprocess.call(cmdline)
> +
> + def _do_abort(self, container_name):
> + subprocess.call(['docker', 'kill', container_name])
> +
> +
> +class PodmanRuntime(ContainerRuntime):
> + """Run a command in a Podman container"""
> +
> + name = 'podman'
> +
> + def _do_run(self, image, cmd, container_name):
> + cmdline = [
> + 'podman', 'run',
> + '--name', container_name,
> + '--rm',
> + '--tty',
> + '--interactive',
> + '--volume', f'{os.getcwd()}:/src',
> + '--workdir', '/src',
> + '--userns', f'keep-id:uid={self._uid},gid={self._gid}',
> + ]
> + if self._env_file:
> + cmdline += ['--env-file', self._env_file]
> + cmdline.append(image)
> + cmdline += cmd
> + return subprocess.call(cmdline)
> +
> + def _do_abort(self, container_name):
> + pass # Signals are handled by Podman in interactive mode
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Nathan Chancellor @ 2025-12-19 21:15 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Miguel Ojeda, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm, Arnd Bergmann
In-Reply-To: <20251219194748.GA1404325@ax162>
On Fri, Dec 19, 2025 at 12:47:48PM -0700, Nathan Chancellor wrote:
> Most of these two functions are the same. Maybe they could be abstracted
> into a simple class so that most of the logic could be shared between
> the two implementations? That also might simplify main() a bit and make
> fulfilling David's request a little simpler as well.
Sigh, this is what I get for working through my inbox bottom up since I
see that you did this in v2 :) looks good, I will give a couple more
comments there.
^ permalink raw reply
* Re: [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Nathan Chancellor @ 2025-12-19 19:47 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Miguel Ojeda, linux-kernel, rust-for-linux, linux-kbuild,
automated-testing, workflows, llvm, Arnd Bergmann
In-Reply-To: <97dec58ebe4161027f13f2215ed9da4a43bc8c47.1765374789.git.gtucker@gtucker.io>
Hi Guillaume,
On Wed, Dec 10, 2025 at 02:58:28PM +0100, Guillaume Tucker 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 for this initial version.
>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Link: https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
Overall, I like the concept here. It is simple and should be relatively
easy for people to drive. I think having some short quick examples (or a
link to the Documentation file that inclues them) would be good in case
people stumble across the script first.
One initial comment (or perhaps feature request) would be handling O= /
KBUILD_OUTPUT for building out of tree. It may be a little complicated
for mounting the build directory into the container but it might make it
easier for folks who build out of tree to use.
> ---
> scripts/container | 112 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 112 insertions(+)
> create mode 100755 scripts/container
>
> diff --git a/scripts/container b/scripts/container
> new file mode 100755
> index 000000000000..74644ac33685
> --- /dev/null
> +++ b/scripts/container
> @@ -0,0 +1,112 @@
> +#!/bin/env python3
> +# SPDX-License-Identifier: GPL-2.0-only
> +# Copyright (C) 2025 Guillaume Tucker
> +
> +"""Containerized builds"""
> +
> +import argparse
> +import logging
> +import os
> +import subprocess
> +import sys
> +
> +
> +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 run_docker(args):
> + """Run a command in a Docker container"""
> + uid = args.uid or os.getuid()
> + gid = args.gid or args.uid or os.getgid()
> + cmd = [
> + 'docker', 'run',
> + '--interactive',
> + '--volume', f'{os.getcwd()}:/src',
Is there a minimum python version required for this? If not, I would
prefer using pathlib here:
from pathlib import Path
then
Path.cwd()
> + '--workdir', '/src',
> + '--user', f'{uid}:{gid}'
> + ]
> + if args.env_file:
> + cmd += ['--env-file', args.env_file]
> + cmd.append(args.image)
> + cmd += args.cmd
> + return subprocess.call(cmd)
> +
> +
> +def run_podman(args):
> + """Run a command in a Podman container"""
> + uid = args.uid or 1000
> + gid = args.gid or args.uid or 1000
Why 1000 instead of using getuid() and getgid() as above?
> + cmd = [
> + 'podman', 'run',
> + '--interactive',
> + '--volume', f'{os.getcwd()}:/src',
> + '--workdir', '/src',
> + '--userns', f'keep-id:uid={uid},gid={gid}',
> + ]
> + if args.env_file:
> + cmd += ['--env-file', args.env_file]
> + cmd.append(args.image)
> + cmd += args.cmd
> + return subprocess.call(cmd)
Most of these two functions are the same. Maybe they could be abstracted
into a simple class so that most of the logic could be shared between
the two implementations? That also might simplify main() a bit and make
fulfilling David's request a little simpler as well.
> +def main(args):
> + """Main entry point for the container tool"""
> + logger = get_logger(args.verbose)
> + logger.debug("runtime=%s, image=%s", args.runtime, args.image)
> + runtimes = {
> + 'docker': run_docker,
> + 'podman': run_podman,
> + }
> + handler = runtimes.get(args.runtime)
> + if not handler:
> + logger.error("Unknown container runtime: %s", args.runtime)
> + return 1
> + try:
> + return handler(args)
> + except KeyboardInterrupt:
> + logger.error("aborted")
> + return 1
> +
> +
> +if __name__ == '__main__':
> + parser = argparse.ArgumentParser("Containerized builds")
> + parser.add_argument(
> + '-e', '--env-file',
> + help="Path to an environment file to load in the container."
> + )
Is there documentation for how an environment file should be formatter?
> + parser.add_argument(
> + '-g', '--gid',
> + help="Group ID to use inside the container."
> + )
> + parser.add_argument(
> + '-i', '--image', default='gcc',
> + help="Container image, default is gcc."
> + )
> + parser.add_argument(
> + '-r', '--runtime', choices=['docker', 'podman'], default='docker',
> + help="Container runtime, default is docker."
> + )
> + 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 used for 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
* Hosting first-party kernel.org container images
From: Guillaume Tucker @ 2025-12-19 13:37 UTC (permalink / raw)
To: Arnd Bergmann, Konstantin Ryabitsev
Cc: Nathan Chancellor, Miguel Ojeda, Onur Özkan,
linux-kernel@vger.kernel.org, workflows, automated-testing,
Ben Copeland
Hi Konstantin, Arnd et al,
This is a follow-up from the series about adding a scripts/container
tool [1] to run kernel builds in containers. As per the discussion
at Plumbers last year and the summary I put in a blog post [2], it
would be great to have container images with kernel.org toolchains
hosted upstream. This can mean several things, so let's break it
down into a set of potential options to choose from:
* Containerfiles Git repository
There is currently a PoC repository on GitLab with a Makefile and a
number of Containerfiles to build a set of images:
https://gitlab.com/gtucker/korg-containers
It can be improved in many ways since this is an early PoC. The key
decision to make here, if we do want to have container images
supported upstream, is how to manage these files or a derived
implementation.
One option is to add it to the kernel tree itself under e.g.
tools/container.
Another option is to add a separate repository on git.kernel.org,
which I believe would be a better approach as there aren't any direct
dependencies on the kernel tree itself.
A third option might be to keep it alongside any recipes used to
produce the existing kernel.org toolchain tarballs although I'm not
entirely sure how that's managed - something for Arnd to judge I
guess.
A last option would be to keep it on GitLab or move it to GitHub
which would provide some CI/CD tools for building the images but I
doubt this is something viable for the kernel community as it would
create some vendor lock-in.
* Container image registry
This is where things get a bit more complicated. As far as I'm
aware, there aren't any container registries hosted in the kernel.org
infrastructure at the moment. A classic option would be to push the
images to an established one e.g. Docker Hub (docker.io) or the
Google Artifact Registry. GitLab and GitHub also provide theirs of
course. I believe there is still a free plan for community projects
to host images on docker.io and that would be the easiest from a user
point of view e.g. "docker pull kernel.org/gcc". It comes with some
maintenance burden of course, and Docker Hub has a history of
changing its policies quite unexpectedly so it's not entirely
future-proof.
A classic alternative would be to host a dedicated service
e.g. registry.kernel.org and have the images managed there. This
would obviously involve higher sysadmin efforts and add scalability
issues but would decouple it from external providers.
Then a third option would be to host the container images as OCI
tarball dumps alongside the toolchain tarballs. They can then be
downloaded and imported with "docker image load" or any other
container runtime. The only infrastructure resources needed would be
storage space. This is of course suboptimal as all the layers get
bundled together and users would have to manage these images
themselves, but it's very effective from a kernel.org sysadmin point
of view.
There are undoubtedly other ways to look at this, I'm curious to know
what people think. The benefits of having readily-available
container images upstream appear to be pretty clear, several
maintainers have expressed their support already. It's all down to
how much these benefits can outweigh the upstream maintenance costs.
Maybe this can be done in two steps, first with just the
Containerfiles and later on a full solution to host the actual
images.
Best wishes,
Guillaume
[1] https://lore.kernel.org/all/cover.1766061692.git.gtucker@gtucker.io/
[2] https://gtucker.io/posts/2024-09-30-korg-containers/
^ permalink raw reply
* [PATCH v2 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2025-12-18 12:49 UTC (permalink / raw)
To: Nathan Chancellor, 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.1766061692.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.
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: David Gow <davidgow@google.com>
Cc: "Onur Özkan" <work@onurozkan.dev>
Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
---
Documentation/dev-tools/container.rst | 175 ++++++++++++++++++++++++++
Documentation/dev-tools/index.rst | 1 +
2 files changed, 176 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..5254feae02c2
--- /dev/null
+++ b/Documentation/dev-tools/container.rst
@@ -0,0 +1,175 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+.. Copyright (C) 2025 Guillaume Tucker
+
+====================
+Containerized Builds
+====================
+
+The ``container`` tool can be used to run any command in the kernel source tree
+from within a container. Doing so facilitates reproducing builds across
+various platforms, for example when a test bot has reported an issue which
+requires a specific version of a compiler or an external test suite. While
+this can already be done by users who are familiar with containers, having a
+dedicated tool in the kernel tree lowers the barrier to entry by solving common
+problems once and for all (e.g. user id management). It also makes it easier
+to share an exact command line leading to a particular result. The main use
+case is likely to be kernel builds but virtually anything can be run: KUnit,
+checkpatch etc. provided a suitable image is available.
+
+
+Options
+=======
+
+Command line syntax::
+
+ scripts/container -i IMAGE [OPTION]... CMD...
+
+Available options:
+
+``-e, --env-file ENV_FILE``
+
+ Path to an environment file to load in the container.
+
+``-g, --gid GID``
+
+ Group id to use inside the container.
+
+``-i, --image IMAGE``
+
+ Container image name (required).
+
+``-r, --runtime RUNTIME``
+
+ Container runtime name. Supported runtimes: ``docker``, ``podman``.
+
+ If not specified, the first one found on the system will be used
+ i.e. Docker if present, otherwise Podman.
+
+``-u, --uid UID``
+
+ User id to use inside the container.
+
+ If the ``-g`` option is not specified, the user id will also be used for
+ the group id.
+
+``-v, --verbose``
+
+ Enable verbose output.
+
+``-h, --help``
+
+ Show the help message and exit.
+
+
+Usage
+=====
+
+It's entirely up to the user to choose which image to use and the ``CMD``
+arguments are passed directly as an arbitrary command line to run in the
+container. The tool will take care of mounting the source tree as the current
+working directory and adjust the user and group id as needed.
+
+The container image which would typically include a compiler toolchain is
+provided by the user and selected via the ``-i`` option. The container runtime
+can be selected with the ``-r`` option, which can be either ``docker`` or
+``podman``. If none is specified, the first one found on the system will be
+used. Support for other runtimes may be added later depending on their
+popularity among users.
+
+
+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.
+
+Please note that ``make`` options can still be passed on the command line, so
+while this can't be done since the first argument needs to be the executable::
+
+ scripts/container -i tuxmake/korg-clang LLVM=1 make
+
+this will work::
+
+ scripts/container -i tuxmake/korg-clang make LLVM=1
+
+
+User IDs
+========
+
+This is an area where the behaviour will vary slightly depending on the
+container runtime. The goal is to run commands as the user invoking the tool.
+With Podman, a namespace is created to map the current user id to a different
+one in the container (1000 by default). With Docker, while this is also
+possible with recent versions it requires a special feature to be enabled in
+the daemon so it's not used here for simplicity. Instead, the container is run
+with the current user id directly. In both cases, this will provide the same
+file permissions for the kernel source tree mounted as a volume. The only
+difference is that when using Docker without a namespace, the user id may not
+be the same as the default one set in the image.
+
+Say, we're using an image which sets up a default user with id 1000 and the
+current user calling the ``container`` tool has id 1234. The kernel source
+tree was checked out by this same user so the files belong to user 1234. With
+Podman, the container will be running as user id 1000 with a mapping to id 1234
+so that the files from the mounted volume appear to belong to id 1000 inside
+the container. With Docker and no namespace, the container will be running
+with user id 1234 which can access the files in the volume but not in the user
+1000 home directory. This shouldn't be an issue when running commands only in
+the kernel tree but it is worth highlighting here as it might matter for
+special corner cases.
+
+
+Examples
+========
+
+The shortest example is to run a basic kernel build using Docker and a tuxmake
+Clang image::
+
+ scripts/container -i tuxmake/korg-clang -- make LLVM=1 defconfig
+ scripts/container -i tuxmake/korg-clang -- make LLVM=1 -j$(nproc)
+
+.. note::
+
+ When running a command with options within the container, it should be
+ separated with a double dash ``--`` to not confuse them with the
+ ``container`` tool options. Plain commands with no options don't strictly
+ require the double dashes e.g.::
+
+ scripts/container -i tuxmake/korg-clang make mrproper
+
+To run ``checkpatch.pl`` in a ``patches`` directory with a generic image::
+
+ scripts/container -i perl:slim-trixie scripts/checkpatch.pl patches/*
+
+The examples below refer to ``kernel.org`` images which are based on the
+`kernel.org compiler toolchains
+<https://mirrors.edge.kernel.org/pub/tools/>`__. These aren't (yet) officially
+available in any public registry but users can build their own locally instead
+using this `experimental repository
+<https://gitlab.com/gtucker/korg-containers>`__ by running ``make
+PREFIX=kernel.org/``.
+
+To build just ``bzImage`` using Clang::
+
+ scripts/container -i kernel.org/clang -- make bzImage -j$(nproc)
+
+Same with GCC 15 as a particular version tag::
+
+ scripts/container -i kernel.org/gcc:15 -- make bzImage -j$(nproc)
+
+To run KUnit::
+
+ scripts/container -i kernel.org/gcc:kunit -- \
+ tools/testing/kunit/kunit.py \
+ run \
+ --arch=x86_64 \
+ --cross_compile=x86_64-linux-
+
+To build the HTML documentation, which requires the ``kdocs`` image built with
+``make PREFIX=kernel.org/ extra`` as it's not a compiler toolchain::
+
+ scripts/container -i kernel.org/kdocs make htmldocs
diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
index 4b8425e348ab..527a0e4cf2ed 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -38,6 +38,7 @@ Documentation/process/debugging/index.rst
gpio-sloppy-logic-analyzer
autofdo
propeller
+ container
.. only:: subproject and html
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-18 12:49 UTC (permalink / raw)
To: Nathan Chancellor, 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.1766061692.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 for this initial version.
Cc: Nathan Chancellor <nathan@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>
---
scripts/container | 194 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100755 scripts/container
diff --git a/scripts/container b/scripts/container
new file mode 100755
index 000000000000..2d0143c7d43e
--- /dev/null
+++ b/scripts/container
@@ -0,0 +1,194 @@
+#!/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 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._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 command in 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 DockerRuntime(ContainerRuntime):
+ """Run a command in a Docker container"""
+
+ name = 'docker'
+
+ def _do_run(self, image, cmd, container_name):
+ cmdline = [
+ 'docker', 'run',
+ '--name', container_name,
+ '--rm',
+ '--tty',
+ '--volume', f'{os.getcwd()}:/src',
+ '--workdir', '/src',
+ '--user', f'{self._uid}:{self._gid}'
+ ]
+ if self._env_file:
+ cmdline += ['--env-file', self._env_file]
+ cmdline.append(image)
+ cmdline += cmd
+ return subprocess.call(cmdline)
+
+ def _do_abort(self, container_name):
+ subprocess.call(['docker', 'kill', container_name])
+
+
+class PodmanRuntime(ContainerRuntime):
+ """Run a command in a Podman container"""
+
+ name = 'podman'
+
+ def _do_run(self, image, cmd, container_name):
+ cmdline = [
+ 'podman', 'run',
+ '--name', container_name,
+ '--rm',
+ '--tty',
+ '--interactive',
+ '--volume', f'{os.getcwd()}:/src',
+ '--workdir', '/src',
+ '--userns', f'keep-id:uid={self._uid},gid={self._gid}',
+ ]
+ if self._env_file:
+ cmdline += ['--env-file', self._env_file]
+ cmdline.append(image)
+ cmdline += cmd
+ return subprocess.call(cmdline)
+
+ def _do_abort(self, container_name):
+ pass # Signals are handled by Podman in interactive mode
+
+
+class Runtimes:
+ """List of all supported runtimes"""
+
+ runtimes = [DockerRuntime, PodmanRuntime]
+
+ @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="Containerized builds. See the dev-tools/container "
+ "kernel documentation section for more details."
+ )
+ 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. Docker if present, otherwise Podman."
+ )
+ 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 v2 0/2] scripts: introduce containerized builds
From: Guillaume Tucker @ 2025-12-18 12:49 UTC (permalink / raw)
To: Nathan Chancellor, 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 an email discussion and a talk at Plumbers
last year:
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 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
#
and a follow-up command to build the kernel with the verbose flag
turned on to show DEBUG log messages from the container tool:
$ scripts/container -i tuxmake/korg-clang-21 -v -- make LLVM=1 -j8
[container DEBUG] runtime: docker
[container DEBUG] image: tuxmake/korg-clang-21
[container DEBUG] container: c5a88761-f55a-4027-84c9-bc3c6dc9c4cd
GEN arch/x86/include/generated/asm/orc_hash.h
HOSTCC scripts/basic/fixdep
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
[...]
BUILD arch/x86/boot/bzImage
Kernel: arch/x86/boot/bzImage is ready (#1)
As a next step to make this tool more useful, 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:
https://gitlab.com/gtucker/korg-containers
Say, to run KUnit using the latest kernel.org GCC toolchain:
scripts/container \
-i registry.gitlab.com/gtucker/korg-containers/gcc:kunit -- \
tools/testing/kunit/kunit.py \
run \
--arch=x86_64 \
--cross_compile=x86_64-linux-
This patch series also include a documentation page with all the
relevant details about how to use the tool and the images currently
available.
---
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 | 175 +++++++++++++++++++++++
Documentation/dev-tools/index.rst | 1 +
scripts/container | 194 ++++++++++++++++++++++++++
3 files changed, 370 insertions(+)
create mode 100644 Documentation/dev-tools/container.rst
create mode 100755 scripts/container
--
2.47.3
^ permalink raw reply
* Re: [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Federico Vaga @ 2025-12-17 22:48 UTC (permalink / raw)
To: Andi Shyti
Cc: linux-doc, linux-kernel, workflows, Jonathan Corbet,
Andy Shevchenko
In-Reply-To: <klzag46p6mlqqdrogqofancqyjpvs5lmwa4m3tjszcgavdwa6s@nay2uuwpsvlt>
Hi Andi,
On Mon, Dec 15, 2025 at 05:14:02PM +0100, Andi Shyti wrote:
>Hi Federico,
>
>> >-Il file di intestazione include/linux/kernel.h contiene un certo numero
>> >-di macro che dovreste usare piuttosto che implementarne una qualche variante.
>> >-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
>> >-macro:
>> >+I file header
>>
>> In Italian, the correct name for "header file" is "file di intestazione".
>> Please, don't replace correct Italian with *Itanglese* :)
>
>I absolutely disagree.
>
>If you open any C book, they are called 'header files', except
>for a few Italian technical books with excessively literal
>translations, where even non-translatable terms are translated.
>
>Italian technical translations usually preserve the original
>English terms as much as possible, which is quite different from
>what often happens in French or German.
>
>'File di intestazione' is a literal word-by-word translation.
>If you want the proper technical term, it is 'header file'.
Both English and Italian terms are borrowed from typography, "that thing you see
on top of your document": the header file. In Italian, we never had a neologism
for "file", but we have a typography glossary. So it becomes "file di
intestazione". A wider audience can quickly understand where to look to find the
mentioned "file" because "intestazione" means at the top ("in testa"), like in
English.
As you rightly mentioned, other languages are more alive than Italian and their
speakers naturally make and use neologisms for the new things popping up in
their lives without scandal. For Italian speakers, these days, it is harder
(already this email shows that I need to justify the use of Italian words in an
Italian document. There are some publications about this problem if you would
like to know more). However, I don't think this should be a justification to
forget that terms exist and should be used. I'm well aware of all possible
variants that you can find in Italian original texts (they exist) or
translations ("I file di intestazione", "L'header", "I file header", "L'header
file"). You wrote that the good one is "header file", but four variants exist
and your rephrase used "file header" (swapped). When I started this work long
ago I had to chose an editorial line, and I chose to use Italian terms: (a) when
they exist, (b) they have sufficient diffusion, and (c) if it adds value for a
wider audience.
For the case at hand, any web search will give you various results using "file
di intestazione". You can also use Google Books. You might still say that is not
your taste because you prefer English words, but it can't be denied that the
term exists and it is used.
On this particular subject, I think we are a bit off-topic. But if you want to
discuss more we can continue aside.
>> >presenti in include/linux mettono a disposizione numerose macro
>> >+che è preferibile utilizzare, evitando di sviluppare implementazioni
>> >+alternative.
>>
>> I think it is less accurate. In English, it tells users what they "should do"
>> and "should not do". It does not speak about what is preferable and what to
>> avoid. I agree that, at the end of the day, one should come at the same
>> conclusions. However, the translation should be as accurate as possible and
>> make adaptations wherever necessary to improve the understanding.
>>
>> A would be perfectly fine if also the English statement changes in the same
>> direction.
>
>I think a literal translation is not beneficial to the final
>text,
It is not a literal translation. It is a translation. For example, if there is a
joke inside the documentation, that joke gets translated no matter my opinion on
that joke or jokes in technical documents in general. If there are implicit,
rather than explicit, references they get translated as such. If the
documentation needs improvement, it must be first done in its original language,
and the translation must follow.
>and we have some room to rephrase it while keeping the original meaning intact.
Why not using that room in English as well? For example:
""" From the patch
Feel free to peruse the header files to see what else is already
defined that you shouldn't reproduce in your code.
"""
""" Your suggestion
È consigliato consultare i vari file header per vedere altre macro già
disponibili.
"""
This reprhase is not anymore -->friendly<-- inviting users to read the header
files and discover new macros, and it is not reminding them that they should do
it to avoid duplicating code, probably incorrect code (the entire intention of
point 18 of the coding style document).
A reprhase for better readability would be greatly appriciated, I'm definively
not Dante. In doing so, remember to not delete things or change the tone of the
original text. If that is your intention, then do the same in English.
P.S. I'm interested in the non-translatable terms you found in Italian books. In
the past I was doing some researches on the topic and I'm genuinly curious to
see what you found there and see their etymology :)
>Andi
>
--
Federico Vaga
^ permalink raw reply
* Re: [Automated-testing] [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-17 13:51 UTC (permalink / raw)
To: David Gow
Cc: Nathan Chancellor, Miguel Ojeda, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm, Arnd Bergmann
In-Reply-To: <CABVgOS=LD_7gTk+qivoLJpAk0susehrCVdazApQAM=9311M4+w@mail.gmail.com>
Hello David,
On 17/12/2025 10:56 am, David Gow wrote:
> On Wed, 10 Dec 2025 at 21:58, Guillaume Tucker via
> lists.yoctoproject.org <gtucker=gtucker.io@lists.yoctoproject.org>
> 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 for this initial version.
>>
>> Cc: Nathan Chancellor <nathan@kernel.org>
>> Cc: Miguel Ojeda <ojeda@kernel.org>
>> Link: https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
>> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
>> ---
>
> I gave this a go, and am liking it so far. My only real complaints are
> that the defaults don't totally match my prejudices. :-)
>
> Having a good default container, and perhaps falling back
> automatically to podman if docker isn't running (or just defaulting to
> podman) would make this very convenient for one-line
> tests/reproducers.
Many thanks for your feedback, I'm glad that worked for you.
Yes, the default 'gcc' image doesn't actually work in practice. I've
proposed something else in another email to drop the default for now
but aim to provide "first-party" container images using kernel.org
toolchains which may give us some useful default later on.
Then good point about the default container runtime, I'll update the
logic to automatically look for Docker and Podman - basically iterate
through the supported runtimes - in the v2.
Cheers,
Guillaume
^ permalink raw reply
* Re: [Automated-testing] [PATCH v1 1/2] scripts: add tool to run containerized builds
From: David Gow @ 2025-12-17 9:56 UTC (permalink / raw)
To: gtucker
Cc: Nathan Chancellor, Miguel Ojeda, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm, Arnd Bergmann
In-Reply-To: <97dec58ebe4161027f13f2215ed9da4a43bc8c47.1765374789.git.gtucker@gtucker.io>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
On Wed, 10 Dec 2025 at 21:58, Guillaume Tucker via
lists.yoctoproject.org <gtucker=gtucker.io@lists.yoctoproject.org>
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 for this initial version.
>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Link: https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
> ---
I gave this a go, and am liking it so far. My only real complaints are
that the defaults don't totally match my prejudices. :-)
Having a good default container, and perhaps falling back
automatically to podman if docker isn't running (or just defaulting to
podman) would make this very convenient for one-line
tests/reproducers.
-- David
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5281 bytes --]
^ permalink raw reply
* Re: [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Andi Shyti @ 2025-12-15 16:14 UTC (permalink / raw)
To: Federico Vaga
Cc: linux-doc, linux-kernel, workflows, Jonathan Corbet,
Andy Shevchenko
In-Reply-To: <zylu4ulxeyni5diwnp7o7evcajqyylhzzd4d2skyi2ul2ayb3b@2kojo3dyp2vi>
Hi Federico,
> >-Il file di intestazione include/linux/kernel.h contiene un certo numero
> >-di macro che dovreste usare piuttosto che implementarne una qualche variante.
> >-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
> >-macro:
> >+I file header
>
> In Italian, the correct name for "header file" is "file di intestazione".
> Please, don't replace correct Italian with *Itanglese* :)
I absolutely disagree.
If you open any C book, they are called 'header files', except
for a few Italian technical books with excessively literal
translations, where even non-translatable terms are translated.
Italian technical translations usually preserve the original
English terms as much as possible, which is quite different from
what often happens in French or German.
'File di intestazione' is a literal word-by-word translation.
If you want the proper technical term, it is 'header file'.
> >presenti in include/linux mettono a disposizione numerose macro
> >+che è preferibile utilizzare, evitando di sviluppare implementazioni
> >+alternative.
>
> I think it is less accurate. In English, it tells users what they "should do"
> and "should not do". It does not speak about what is preferable and what to
> avoid. I agree that, at the end of the day, one should come at the same
> conclusions. However, the translation should be as accurate as possible and
> make adaptations wherever necessary to improve the understanding.
>
> A would be perfectly fine if also the English statement changes in the same
> direction.
I think a literal translation is not beneficial to the final
text, and we have some room to rephrase it while keeping the
original meaning intact.
Andi
^ permalink raw reply
* Re: [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-15 10:15 UTC (permalink / raw)
To: Onur Özkan
Cc: Nathan Chancellor, Miguel Ojeda, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm, Arnd Bergmann
In-Reply-To: <20251215122407.720d65bf@nimda>
Hi Onur,
On 15/12/2025 10:24 am, Onur Özkan wrote:
> Hi Guillaume,
>
> Excellent work! Just one note from my side so far:
Thanks for the review!
> On Wed, 10 Dec 2025 14:58:28 +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 for this initial version.
>>
>> Cc: Nathan Chancellor<nathan@kernel.org>
>> Cc: Miguel Ojeda<ojeda@kernel.org>
>> Link:
>> https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-
>> a7965c19ac4e@gtucker.io/
>> Signed-off-by: Guillaume Tucker<gtucker@gtucker.io> ---
>> scripts/container | 112
>> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112
>> insertions(+) create mode 100755 scripts/container
>>
>> diff --git a/scripts/container b/scripts/container
>> new file mode 100755
>> index 000000000000..74644ac33685
>> --- /dev/null
>> +++ b/scripts/container
>> @@ -0,0 +1,112 @@
>> +#!/bin/env python3
> By default, this will not work on NixOS because /bin/env is
> not a valid path.
>
> It will fail like this:
>
> $ cat something
> #!/bin/env python3
>
> $ ./something
> zsh: ./something: bad interpreter: /bin/env: no such file or
> directory
>
> Is there a reason for not using /usr/bin/env?
Ah sorry, my bad. I initially started writing this as a shell script
using /bin/sh and typed it wrong when changing to Python. So I'll
fix it in v2, thanks for flagging this (pylint didn't...).
Another change I want to make is to drop the default image as 'gcc'
doesn't really help. If the user hasn't set a custom tag, it will
pull some generic image from docker.io which won't have all the tools
needed to build a kernel. So making the -i option required or
turning it into a positional argument would be better than some
implicit behaviour. I'll start a separate thread with Konstantin and
Arnd about hosting kernel.org toolchain container images as having
that should make the tool much more useful and we might set valid
default values e.g. kernel.org/gcc.
Cheers,
Guillaume
^ permalink raw reply
* Re: [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Onur Özkan @ 2025-12-15 9:24 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Nathan Chancellor, Miguel Ojeda, linux-kernel, rust-for-linux,
linux-kbuild, automated-testing, workflows, llvm, Arnd Bergmann
In-Reply-To: <97dec58ebe4161027f13f2215ed9da4a43bc8c47.1765374789.git.gtucker@gtucker.io>
Hi Guillaume,
Excellent work! Just one note from my side so far:
On Wed, 10 Dec 2025 14:58:28 +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 for this initial version.
>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Link:
> https://lore.kernel.org/all/affb7aff-dc9b-4263-bbd4-a7965c19ac4e@gtucker.io/
> Signed-off-by: Guillaume Tucker <gtucker@gtucker.io> ---
> scripts/container | 112
> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112
> insertions(+) create mode 100755 scripts/container
>
> diff --git a/scripts/container b/scripts/container
> new file mode 100755
> index 000000000000..74644ac33685
> --- /dev/null
> +++ b/scripts/container
> @@ -0,0 +1,112 @@
> +#!/bin/env python3
By default, this will not work on NixOS because /bin/env is
not a valid path.
It will fail like this:
$ cat something
#!/bin/env python3
$ ./something
zsh: ./something: bad interpreter: /bin/env: no such file or
directory
Is there a reason for not using /usr/bin/env?
> +# SPDX-License-Identifier: GPL-2.0-only
> +# Copyright (C) 2025 Guillaume Tucker
> +
> +"""Containerized builds"""
> +
> +import argparse
> +import logging
> +import os
> +import subprocess
> +import sys
> +
> +
> +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 run_docker(args):
> + """Run a command in a Docker container"""
> + uid = args.uid or os.getuid()
> + gid = args.gid or args.uid or os.getgid()
> + cmd = [
> + 'docker', 'run',
> + '--interactive',
> + '--volume', f'{os.getcwd()}:/src',
> + '--workdir', '/src',
> + '--user', f'{uid}:{gid}'
> + ]
> + if args.env_file:
> + cmd += ['--env-file', args.env_file]
> + cmd.append(args.image)
> + cmd += args.cmd
> + return subprocess.call(cmd)
> +
> +
> +def run_podman(args):
> + """Run a command in a Podman container"""
> + uid = args.uid or 1000
> + gid = args.gid or args.uid or 1000
> + cmd = [
> + 'podman', 'run',
> + '--interactive',
> + '--volume', f'{os.getcwd()}:/src',
> + '--workdir', '/src',
> + '--userns', f'keep-id:uid={uid},gid={gid}',
> + ]
> + if args.env_file:
> + cmd += ['--env-file', args.env_file]
> + cmd.append(args.image)
> + cmd += args.cmd
> + return subprocess.call(cmd)
> +
> +
> +def main(args):
> + """Main entry point for the container tool"""
> + logger = get_logger(args.verbose)
> + logger.debug("runtime=%s, image=%s", args.runtime, args.image)
> + runtimes = {
> + 'docker': run_docker,
> + 'podman': run_podman,
> + }
> + handler = runtimes.get(args.runtime)
> + if not handler:
> + logger.error("Unknown container runtime: %s", args.runtime)
> + return 1
> + try:
> + return handler(args)
> + except KeyboardInterrupt:
> + logger.error("aborted")
> + return 1
> +
> +
> +if __name__ == '__main__':
> + parser = argparse.ArgumentParser("Containerized builds")
> + 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', default='gcc',
> + help="Container image, default is gcc."
> + )
> + parser.add_argument(
> + '-r', '--runtime', choices=['docker', 'podman'],
> default='docker',
> + help="Container runtime, default is docker."
> + )
> + 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 used for 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:])))
-Onur
^ permalink raw reply
* Re: [PATCH] Doc:it_IT: Do not reference kernel.h anymore
From: Federico Vaga @ 2025-12-15 0:30 UTC (permalink / raw)
To: Andi Shyti
Cc: linux-doc, linux-kernel, workflows, Jonathan Corbet,
Andy Shevchenko
In-Reply-To: <20251205111559.3089219-1-andi.shyti@kernel.org>
Hi Andi,
thank you for contributing to the Italian translation.
On Fri, Dec 05, 2025 at 12:15:58PM +0100, Andi Shyti wrote:
>I also took the chance to improve the phrasing in a few places.
As a technical translation, we should not try to make reinterpretation of the
original text. See comments below.
>Andi
>
> .../it_IT/process/coding-style.rst | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
>diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst
>index c0dc786b8474..b2fd74528de5 100644
>--- a/Documentation/translations/it_IT/process/coding-style.rst
>+++ b/Documentation/translations/it_IT/process/coding-style.rst
>@@ -1068,15 +1068,17 @@ può migliorare la leggibilità.
> 18) Non reinventate le macro del kernel
> ---------------------------------------
>
>-Il file di intestazione include/linux/kernel.h contiene un certo numero
>-di macro che dovreste usare piuttosto che implementarne una qualche variante.
>-Per esempio, se dovete calcolare la lunghezza di un vettore, sfruttate la
>-macro:
>+I file header
In Italian, the correct name for "header file" is "file di intestazione".
Please, don't replace correct Italian with *Itanglese* :)
>presenti in include/linux mettono a disposizione numerose macro
>+che è preferibile utilizzare, evitando di sviluppare implementazioni
>+alternative.
I think it is less accurate. In English, it tells users what they "should do"
and "should not do". It does not speak about what is preferable and what to
avoid. I agree that, at the end of the day, one should come at the same
conclusions. However, the translation should be as accurate as possible and
make adaptations wherever necessary to improve the understanding.
A would be perfectly fine if also the English statement changes in the same
direction.
Including your suggestions I would write:
"""
I file di intestazione presenti in include/linux mettono a disposizione numerose
macro che dovreste utilizzare piuttosto che implementarne delle varianti.
"""
>@@ -1084,10 +1086,11 @@ struttura, usate
>
> #define sizeof_field(t, f) (sizeof(((t*)0)->f))
>
>-Ci sono anche le macro min() e max() che, se vi serve, effettuano un controllo
>-rigido sui tipi. Sentitevi liberi di leggere attentamente questo file
>-d'intestazione per scoprire cos'altro è stato definito che non dovreste
>-reinventare nel vostro codice.
>+definita in stddef.h.
>+
>+Ci sono anche le macro min() e max() definite in minmax.h che effettuano un
>+controllo rigoroso sui tipi.
Here it is loosing the "if you need them". If removed here, it should be removed
also in the English version. Of course, one use functions if they are needed, it
comes without saying.
>È consigliato consultare i vari file header per
>+vedere altre macro già disponibili.
"file header" -> "file di intestazione"
Here, the English text is more colloquial and speaks to users with some irony.
In your adaptation these things are lost. Which is fine if also the English version
looses it with a more cold/professional "It is recommanded reading ...".
--
Federico Vaga
^ permalink raw reply
* Re: [PATCH v1 1/2] scripts: add tool to run containerized builds
From: Guillaume Tucker @ 2025-12-13 4:16 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda
Cc: linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm, Arnd Bergmann, Onur Özkan
In-Reply-To: <97dec58ebe4161027f13f2215ed9da4a43bc8c47.1765374789.git.gtucker@gtucker.io>
[+Onur - sorry I didn't Cc you when sending this series]
On 10/12/2025 2:58 pm, Guillaume Tucker wrote:
> +def run_docker(args):
> + """Run a command in a Docker container"""
> + uid = args.uid or os.getuid()
> + gid = args.gid or args.uid or os.getgid()
> + cmd = [
> + 'docker', 'run',
> + '--interactive',
> + '--volume', f'{os.getcwd()}:/src',
> + '--workdir', '/src',
> + '--user', f'{uid}:{gid}'
> + ]
> + if args.env_file:
> + cmd += ['--env-file', args.env_file]
> + cmd.append(args.image)
> + cmd += args.cmd
> + return subprocess.call(cmd)
Just realised that it also needs a TTY to handle Ctrl-C signals
correctly, otherwise the Python process would stop but the container
would keep running in a detached process (same for podman):
diff --git a/scripts/container b/scripts/container
index 74644ac33685..e05425c06d28 100755
--- a/scripts/container
+++ b/scripts/container
@@ -30,6 +30,7 @@ def run_docker(args):
cmd = [
'docker', 'run',
'--interactive',
+ '--tty',
'--volume', f'{os.getcwd()}:/src',
'--workdir', '/src',
'--user', f'{uid}:{gid}'
I'll send a v2 next week, but I'll wait a bit for any feedback first.
Thanks,
Guillaume
^ permalink raw reply related
* [PATCH v1 2/2] Documentation: dev-tools: add container.rst page
From: Guillaume Tucker @ 2025-12-10 13:58 UTC (permalink / raw)
To: Nathan Chancellor, Miguel Ojeda
Cc: linux-kernel, rust-for-linux, linux-kbuild, automated-testing,
workflows, llvm, Arnd Bergmann, Guillaume Tucker
In-Reply-To: <cover.1765374789.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.
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Guillaume Tucker <gtucker@gtucker.io>
---
Documentation/dev-tools/container.rst | 175 ++++++++++++++++++++++++++
Documentation/dev-tools/index.rst | 1 +
2 files changed, 176 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..2a56f256f648
--- /dev/null
+++ b/Documentation/dev-tools/container.rst
@@ -0,0 +1,175 @@
+.. 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 [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, default is ``gcc``.
+
+``-r, --runtime RUNTIME``
+
+ Container runtime, default is ``docker``. Supported runtimes: ``docker``,
+ ``podman``.
+
+``-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 images are provided by the user and selected via the ``-i``
+option. They will typically include a compiler toolchain to build the kernel
+and as such, the default image tag is set to ``gcc`` to give a convenient way
+of running builds. Any local image with a GCC compiler toolchain could be
+tagged as ``gcc`` to make it point to it. For example::
+
+ docker tag my-user/gcc:15 gcc
+
+The container runtime can be selected with the ``-r`` option, which can be
+either Docker or Podman. Support for other runtimes may be added later
+depending on their popularity among users.
+
+
+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 would most likely have ``LLVM=1`` defined. The local
+environment file is more useful for user-specific variables during development.
+
+Please note that ``make`` options can still be passed on the command line, so
+while this can't be done as the first argument needs to be the executable::
+
+ scripts/container INSTALL_MOD_STRIP=1 make modules_install
+
+this will work::
+
+ scripts/container make modules_install INSTALL_MOD_STRIP=1
+
+
+User IDs
+========
+
+This is an area where the behaviour will vary slightly depending on the
+container runtime. The goal is to run commands as the user invoking the tool.
+With Podman, a namespace is created to map the current user id to a different
+one in the container (1000 by default). With Docker, while this is also
+possible with recent versions it requires a special feature to be enabled in
+the daemon so it's not used here for simplicity. Instead, the container is run
+with the current user id directly. In both cases, this will provide the same
+file permissions for the kernel source tree mounted as a volume. The only
+difference is that when using Docker without a namespace, the user id may not
+be the same as the default one set in the image.
+
+Say, we're using an image which sets up a default user with id 1000 and the
+current user calling the ``container`` tool has id 1234. The kernel source
+tree was checked out by this same user so the files belong to user 1234. With
+Podman, the container will be running as user id 1000 with a mapping to id 1234
+so that the files from the mounted volume appear to belong to id 1000 inside
+the container. With Docker and no namespace, the container will be running
+with user id 1234 which can access the files in the volume but not in the user
+1000 home directory. This shouldn't be an issue when running commands only in
+the kernel tree but it is worth highlighting here as it might matter for
+special corner cases.
+
+
+Examples
+========
+
+The shortest example is to run a basic kernel build using Docker and the
+default ``gcc`` image::
+
+ scripts/container -- make defconfig
+ scripts/container -- make -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. Simple make targets with no options don't
+ strictly require the double dashes e.g.::
+
+ scripts/container make mrproper
+
+To run ``checkpatch.pl`` in a ``patches`` directory with a generic image::
+
+ scripts/container -i perl:slim-trixie scripts/checkpatch.pl patches/*
+
+To build using the TuxMake Clang image::
+
+ scripts/container -i tuxmake/x86_64_korg-clang -- make LLVM=1 -j$(nproc)
+
+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) 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)
+
+To run KUnit::
+
+ scripts/container -i kernel.org/gcc:kunit -- \
+ tools/testing/kunit/kunit.py \
+ run \
+ --arch=x86_64 \
+ --cross_compile=x86_64-linux-
+
+To build the HTML documentation, which requires the ``kdocs`` image built with
+``make PREFIX=kernel.org/ extra`` as it's not a compiler toolchain::
+
+ scripts/container -i kernel.org/kdocs make htmldocs
diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
index 4b8425e348ab..527a0e4cf2ed 100644
--- a/Documentation/dev-tools/index.rst
+++ b/Documentation/dev-tools/index.rst
@@ -38,6 +38,7 @@ Documentation/process/debugging/index.rst
gpio-sloppy-logic-analyzer
autofdo
propeller
+ container
.. only:: subproject and html
--
2.47.3
^ permalink raw reply related
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