include/linux/bootconfig.h | 3 +++ init/main.c | 45 ---------------------------------- lib/bootconfig.c | 56 +++++++++++++++++++++++++++++++++++++++++++ tools/bootconfig/main.c | 60 +++++++++++++++++++++++++++++++++++++++------- 4 files changed, 111 insertions(+), 53 deletions(-)
Add a bootconfig -> kernel cmdline rendering capability shared between
the kernel parser library and the userspace tools/bootconfig binary.
The new userspace mode "tools/bootconfig -C <file>" walks a bootconfig
file's "kernel" subtree and prints it as a flat, space-separated
cmdline string suitable for direct use as (or appending to) a kernel
command line.
This series prepares tools/bootconfig and lib/bootconfig.c for an
upcoming feature that lets the kernel build render an embedded
bootconfig file's "kernel" subtree to a flat cmdline string and embed
it in the kernel image.
The follow-up series (sent separately) wires this into setup_arch() so
early_param() handlers see values supplied via CONFIG_BOOT_CONFIG_EMBED_FILE,
following Masami suggestion in [1]
These two patches are pure groundwork. They add no kernel feature,
change no runtime behavior, and are useful on their own (the new
"tools/bootconfig -C" mode lets anyone render a .bootconfig file to
a cmdline string from the shell).
Landing them independently lets the follow-up series focus on the
kernel-side plumbing without dragging the refactor and tool addition
through the same review cycle.
Patch 1 lifts xbc_snprint_cmdline() from init/main.c into
lib/bootconfig.c so both the kernel runtime path
(xbc_make_cmdline -> extra_command_line) and the userspace tool can
share a single renderer.
- tools/bootconfig already compiles lib/bootconfig.c directly, so no
new shared-code mechanism is introduced.
Patch 2 adds a -C option to tools/bootconfig that walks the "kernel"
subtree of a bootconfig file and prints it as a flat, space-separated
cmdline string. Missing or empty kernel.* produces empty output and
exits 0.
- This is the renderer the kernel build will invoke.
Once this lands, the follow up patches will use it in the following way:
1) Render at build time.
The kernel build invokes the userspace bootconfig tool — using the -C mode
prep added — to convert the embedded bootconfig file into a flat kernel cmdline
string.
2) Bake the string into the kernel image.
A small assembly stub embeds the rendered file into the kernel's discardable
read-only init data, bracketed by two markers so the runtime can locate it.
3) Add a runtime helper to consume it.
A new helper in the shared bootconfig source — sitting next to the renderer
prep moved there — prepends the embedded blob to a cmdline buffer, panicking
rather than truncating if it overflows. The public header declares it with a
no-op stub when the feature is off.
4) Plumb it at architecture early setup.
The arch's early setup calls the helper after the existing builtin-cmdline
merge but before early-param parsing, so values from the embedded bootconfig
influence early-param handlers (console, log level, memory overrides) right
when architecture setup runs — not later in
Background: the v1 attempt at this feature moved bootconfig parsing
before setup_arch() with ~96KB of static __initdata buffers [1].
Masami suggested doing the conversion at build time instead [2], which
avoids the early-boot allocator dance and the start_kernel() reordering.
This series, plus the follow-up, aims to implement that approach.
[1] https://lore.kernel.org/all/20260415-bootconfig_earlier-v1-0-cf160175de5e@debian.org/
[2] https://lore.kernel.org/all/20260417104436.ece29fd5e2cb7a59c8cf8ac1@kernel.org/
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (2):
bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c
tools/bootconfig: render kernel.* subtree as cmdline string with -C
include/linux/bootconfig.h | 3 +++
init/main.c | 45 ----------------------------------
lib/bootconfig.c | 56 +++++++++++++++++++++++++++++++++++++++++++
tools/bootconfig/main.c | 60 +++++++++++++++++++++++++++++++++++++++-------
4 files changed, 111 insertions(+), 53 deletions(-)
---
base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
change-id: 20260508-bootconfig_using_tools-cfa7aa9d6a5a
Best regards,
--
Breno Leitao <leitao@debian.org>
On Fri, 08 May 2026 06:55:02 -0700 Breno Leitao <leitao@debian.org> wrote: > Add a bootconfig -> kernel cmdline rendering capability shared between > the kernel parser library and the userspace tools/bootconfig binary. > > The new userspace mode "tools/bootconfig -C <file>" walks a bootconfig > file's "kernel" subtree and prints it as a flat, space-separated > cmdline string suitable for direct use as (or appending to) a kernel > command line. > > This series prepares tools/bootconfig and lib/bootconfig.c for an > upcoming feature that lets the kernel build render an embedded > bootconfig file's "kernel" subtree to a flat cmdline string and embed > it in the kernel image. > > The follow-up series (sent separately) wires this into setup_arch() so > early_param() handlers see values supplied via CONFIG_BOOT_CONFIG_EMBED_FILE, > following Masami suggestion in [1] > > These two patches are pure groundwork. They add no kernel feature, > change no runtime behavior, and are useful on their own (the new > "tools/bootconfig -C" mode lets anyone render a .bootconfig file to > a cmdline string from the shell). > > Landing them independently lets the follow-up series focus on the > kernel-side plumbing without dragging the refactor and tool addition > through the same review cycle. I'll assume that Masami will process this, although `scripts/get_maintainer.pl lib/bootconfig.c' doesn't mention a git tree. https://sashiko.dev/#/patchset/20260508-bootconfig_using_tools-v1-0-1132219aa773@debian.org says a bunch of picky things which seem pretty ignorable to me. Your call ;)
On Fri, May 08, 2026 at 02:56:41PM -0700, Andrew Morton wrote: > On Fri, 08 May 2026 06:55:02 -0700 Breno Leitao <leitao@debian.org> wrote: > > > Add a bootconfig -> kernel cmdline rendering capability shared between > > the kernel parser library and the userspace tools/bootconfig binary. > > > > The new userspace mode "tools/bootconfig -C <file>" walks a bootconfig > > file's "kernel" subtree and prints it as a flat, space-separated > > cmdline string suitable for direct use as (or appending to) a kernel > > command line. > > > > This series prepares tools/bootconfig and lib/bootconfig.c for an > > upcoming feature that lets the kernel build render an embedded > > bootconfig file's "kernel" subtree to a flat cmdline string and embed > > it in the kernel image. > > > > The follow-up series (sent separately) wires this into setup_arch() so > > early_param() handlers see values supplied via CONFIG_BOOT_CONFIG_EMBED_FILE, > > following Masami suggestion in [1] > > > > These two patches are pure groundwork. They add no kernel feature, > > change no runtime behavior, and are useful on their own (the new > > "tools/bootconfig -C" mode lets anyone render a .bootconfig file to > > a cmdline string from the shell). > > > > Landing them independently lets the follow-up series focus on the > > kernel-side plumbing without dragging the refactor and tool addition > > through the same review cycle. > > I'll assume that Masami will process this, although > `scripts/get_maintainer.pl lib/bootconfig.c' doesn't mention a git > tree. > > https://sashiko.dev/#/patchset/20260508-bootconfig_using_tools-v1-0-1132219aa773@debian.org > says a bunch of picky things which seem pretty ignorable to me. Your > call ;) Well, these are some warnings about not checking that the output was properly set. From my view, these are not new to this patch, it is just the pattern we see, which is fire-and-forget writes to stdout, which seems quite reasonable. If we decide to fix this, it would make more sense to do it file-wide instead of just in this patch code.
On Mon, 11 May 2026 09:38:25 -0700 Breno Leitao <leitao@debian.org> wrote: > On Fri, May 08, 2026 at 02:56:41PM -0700, Andrew Morton wrote: > > On Fri, 08 May 2026 06:55:02 -0700 Breno Leitao <leitao@debian.org> wrote: > > > > > Add a bootconfig -> kernel cmdline rendering capability shared between > > > the kernel parser library and the userspace tools/bootconfig binary. > > > > > > The new userspace mode "tools/bootconfig -C <file>" walks a bootconfig > > > file's "kernel" subtree and prints it as a flat, space-separated > > > cmdline string suitable for direct use as (or appending to) a kernel > > > command line. > > > > > > This series prepares tools/bootconfig and lib/bootconfig.c for an > > > upcoming feature that lets the kernel build render an embedded > > > bootconfig file's "kernel" subtree to a flat cmdline string and embed > > > it in the kernel image. > > > > > > The follow-up series (sent separately) wires this into setup_arch() so > > > early_param() handlers see values supplied via CONFIG_BOOT_CONFIG_EMBED_FILE, > > > following Masami suggestion in [1] > > > > > > These two patches are pure groundwork. They add no kernel feature, > > > change no runtime behavior, and are useful on their own (the new > > > "tools/bootconfig -C" mode lets anyone render a .bootconfig file to > > > a cmdline string from the shell). > > > > > > Landing them independently lets the follow-up series focus on the > > > kernel-side plumbing without dragging the refactor and tool addition > > > through the same review cycle. > > > > I'll assume that Masami will process this, although > > `scripts/get_maintainer.pl lib/bootconfig.c' doesn't mention a git > > tree. > > > > https://sashiko.dev/#/patchset/20260508-bootconfig_using_tools-v1-0-1132219aa773@debian.org > > says a bunch of picky things which seem pretty ignorable to me. Your > > call ;) > > Well, these are some warnings about not checking that the output was > properly set. From my view, these are not new to this patch, it is just the > pattern we see, which is fire-and-forget writes to stdout, which seems > quite reasonable. I confirmed there was no problem with UBSAN. "NULL + 1" is undefined, yes, but "(char *)NULL + 1" is sane. > > If we decide to fix this, it would make more sense to do it file-wide > instead of just in this patch code. So no need to fix it. Let me pick this series. Thanks! -- Masami Hiramatsu (Google) <mhiramat@kernel.org>
© 2016 - 2026 Red Hat, Inc.