On Tue, 09 Jun 2026 03:28:33 -0700 Breno Leitao <[email protected]> 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) 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)? Thank you, -- Masami Hiramatsu (Google) <[email protected]>
