On Wed, Jun 10, 2026 at 11:37:20PM +0900, Masami Hiramatsu wrote:
On Tue, 09 Jun 2026 03:28:33 -0700
Breno Leitao [off-list ref] wrote:
quoted
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