Re: [PATCH 0/2] tools/bootconfig: render kernel.* subtree as a cmdline string

From
Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date
2026-05-12 00:43:41
Also in
lkml
Reply to
Breno Leitao, 2026-05-11
On Mon, 11 May 2026 09:38:25 -0700
Breno Leitao [off-list ref] wrote:
On Fri, May 08, 2026 at 02:56:41PM -0700, Andrew Morton wrote:
quoted
On Fri, 08 May 2026 06:55:02 -0700 Breno Leitao [off-list ref] wrote:
quoted
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) [off-list ref]
Thread (8 messages) 8 messages, 3 authors, last reply 2026-05-12
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help