On Mon, 11 May 2026 09:38:25 -0700 Breno Leitao <[email protected]> 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 <[email protected]> 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/[email protected] > > 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) <[email protected]>
