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

[Breno Leitao <leitao@debian.org>]

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.