Re: [PATCH v4 6/7] Documentation: bootconfig: document build-time cmdline rendering

[Breno Leitao <leitao@debian.org>]

On Wed, Jun 10, 2026 at 11:37:20PM +0900, Masami Hiramatsu wrote:
> On Tue, 09 Jun 2026 03:28:33 -0700
> Breno Leitao <leitao@debian.org> wrote:
> 
> > Add a section describing CONFIG_BOOT_CONFIG_EMBED_CMDLINE: what it
> > does (renders the embedded "kernel" subtree to a flat cmdline at
> > build time so early_param() handlers see the values), what it
> > requires (BOOT_CONFIG_EMBED, a non-empty BOOT_CONFIG_EMBED_FILE,
> > and ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG -- currently x86 only),
> > the bootconfig opt-in semantics, the initrd-vs-embedded precedence,
> > and the soft-error overflow behavior.
> 
> Hi Breno,
> 
> Thanks for adding the document. But related to the Sashiko's comment,
> I believe it's necessary to pre-describe in this document how the
> kernel behaves with various combinations of cmdline and bootconfig,
> both embbedded and initrd/bootloader.
> 
> We can have these ways to pass the kernel options.
> 
> - bootloader cmdline
> - embedded cmdline
> - initrd bootconfig
> - embedded bootconfig (standard/cmdline)

Will do.  For v5 I'll extend bootconfig.rst with a section that walks through
each combination -- which source wins, when parse_early_param() sees it, and
how it shows up in /proc/cmdline and /proc/bootconfig.

> Clearly, we will have the option to choose between a standard embedded
> boot configuration or a command-line one, not either, but the behavior
> is different. I confirmed that is covered.
> 
> Embedded bootconfig is a kind of default bootconfig, which is NOT used
> when initrd has another bootconfig. I made this design because of
> /proc/bootconfig, which is not merged with embedded one. However, 
> CONFIG_BOOT_CONFIG_EMBED_CMDLINE will be a bit different, if it is
> embedded and "bootconfig" feature is enabled, the embbedded one
> has been used already. 
> 
> To avoid confusion, when this option is used, shouldn't we treat it
> the same way as if embedded command lines were enabled, and either
> not display it in /proc/bootconfig (or always display it, by merging
> the rendered string)?

You're right that EMBED_CMDLINE breaks it: the embedded kernel.* keys
are already in boot_command_line before setup_boot_config() ever sees
the initrd bconf, so a user reading /proc/bootconfig would see only
the initrd keys while parse_early_param() acted on the embedded ones.
That's exactly the split-state Sashiko was circling around.

Both options you suggest work for me, but they pull in opposite
directions and I'd rather not guess wrong on the user-facing
contract.  Which do you prefer for v5?

  (a) Don't display embedded in /proc/bootconfig -- keep the current
      "file shows the active bootconfig source" behavior and document
      that with EMBED_CMDLINE=y, the kernel.* subtree may have been
      applied separately via the cmdline.

  (b) Always display embedded by merging the rendered string into
      /proc/bootconfig when EMBED_CMDLINE=y, so the file reflects
      what was actually applied.

Happy to go either way

Thanks for the direction,
--breno