Hi Breno,
On Mon, 22 Jun 2026 05:30:53 -0700
Breno Leitao [off-list ref] wrote:
On Thu, Jun 18, 2026 at 09:47:19AM +0900, Masami Hiramatsu wrote:
quoted
On Wed, 17 Jun 2026 02:56:23 -0700
Breno Leitao [off-list ref] wrote:
quoted
On Wed, Jun 10, 2026 at 07:58:10AM -0700, Breno Leitao wrote:
quoted
On Wed, Jun 10, 2026 at 11:37:20PM +0900, Masami Hiramatsu wrote:
quoted
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
Following up on my own mail rather than leaving it fully open: after
looking at the code more, I'd like to recommend (a).
Agreed. Sorry for replying late.
No problem, thanks. Quick heads-up: v5 already went out and crossed with
this mail. It takes (a) and extends bootconfig.rst to walk through the
four sources (bootloader cmdline, embedded cmdline, initrd bootconfig,
embedded bootconfig), so that part is already in flight:
https://lore.kernel.org/r/20260617-bootconfig_using_tools-v5-0-fd589a9cc5e3@debian.org (local)
The naming/mutual-exclusion rework below I'll fold into v6.
Yeah, thanks for updating!
quoted
Indeed. So I think this EMBED_CMDLINE is more like CMDLINE set by
bootconfig file, instead of embedded string. That is useful for reusing
the boot options. We need to change the explanation and clarify it.
Agreed, that's a much clearer model. v6 will reframe the Kconfig help and
bootconfig.rst around "this is CONFIG_CMDLINE, sourced from a bootconfig
file at build time" rather than "an embedded bootconfig that also feeds
the cmdline".
Nice!
It also matches what the code already does precedence-wise: the rendered
"kernel" string is prepended to boot_command_line in setup_arch(), so it
sits in front of the bootloader args and parse_args() last-wins lets the
bootloader override it -- i.e. exactly CONFIG_CMDLINE without _OVERRIDE.
So this is mostly a rename + dependency + docs change, not a behavioral
one. (A _FORCE/_EXTEND-style variant could come later if there's demand;
the current behavior is the plain "overridable default" one.)
OK. Yeah, for the first step, I think current behavior is enough.
quoted
Thus we should those configs mutual exclusive. If user already sets the
CONFIG_CMDLINE, EMBED_CMDLINE should not be enabled.
Makes sense -- two built-in cmdline sources at once is confusing. I'll
make them mutually exclusive in v6. I'm thinking:
depends on CMDLINE = ""
on the new symbol. On x86 CONFIG_CMDLINE is a string that depends on
CMDLINE_BOOL and defaults to "", so this reads as "only offer the
bootconfig-rendered cmdline when no static CONFIG_CMDLINE is configured",
and it works the same on other arches that define CMDLINE as a string.
Does that match what you had in mind, or would you rather gate it the
other way (CMDLINE depends on !the-new-symbol)?
No, this looks good and enough clear to me.
quoted
So you can see CONFIG_BOOT_CONFIG_EMBED_CMDLINE is a bit special.
I think it maybe natual that we call it CONFIG_CMDLINE_BOOT_CONFIG.
In this case, we render the cmdline string from bootconfig build-time
and set CONFIG_CMDLINE with the rendered cmdline string.
So you can see CONFIG_BOOT_CONFIG_EMBED_CMDLINE is a bit special.
I think it maybe natual that we call it CONFIG_CMDLINE_BOOT_CONFIG.
In this case, we render the cmdline string from bootconfig build-time
and set CONFIG_CMDLINE with the rendered cmdline string.
I'll rename it for v6. One nit: the arch opt-in symbol is already
ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG, so CONFIG_CMDLINE_FROM_BOOTCONFIG would
pair with it verbatim. I'll use CONFIG_CMDLINE_FROM_BOOTCONFIG I'll rename it
for v6.
Yeah, thanks!
Another nit: the arch opt-in symbol is already
ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG, so CONFIG_CMDLINE_FROM_BOOTCONFIG would
pair with it verbatim. I'll use CONFIG_CMDLINE_FROM_BOOTCONFIG unless you'd
rather keep CONFIG_CMDLINE_BOOT_CONFIG -- either is fine by me.
I think it should use the same pattern to avoid confusion.
One clarification on "set CONFIG_CMDLINE with the rendered string":
CONFIG_CMDLINE is a Kconfig string fixed when .config is read, while the
render happens later during the build, so we can't literally store the
rendered text into CONFIG_CMDLINE. The mechanism stays "render into
.init.rodata, merge into boot_command_line in setup_arch()"; what changes
is how we name and document it, plus the mutual exclusion above. Let me
Yes, it is fine to me because it does not change the current behavior.
quoted
So you can see CONFIG_BOOT_CONFIG_EMBED_CMDLINE is a bit special.
I think it maybe natual that we call it CONFIG_CMDLINE_BOOT_CONFIG.
I'll rename it for v6. One nit: the arch opt-in symbol is already
ARCH_SUPPORTS_CMDLINE_FROM_BOOTCONFIG, so CONFIG_CMDLINE_FROM_BOOTCONFIG
would pair with it verbatim. I'll use CONFIG_CMDLINE_FROM_BOOTCONFIG
Yes, that's better to be renamed.
quoted
In this case, we render the cmdline string from bootconfig build-time
and set CONFIG_CMDLINE with the rendered cmdline string.
CONFIG_CMDLINE is a Kconfig string fixed when .config is read, while the
render happens later during the build, so we can't literally store the
rendered text into CONFIG_CMDLINE? let me know if you can envision a way to
get it done.
Ah, ok. Nevermind, as far as it is shown in /proc/cmdline, I think it is OK.
(BTW, if we use the embedded bootconfig, the file path is shown in
/proc/config.gz, maybe I need to notice it.)
quoted
I think we can proceed it without rendering it in /proc/bootconfig
at this point. And later we find the way to detect early parameters
correctly, we can fix it.
Sounds good. I'll document the sharp edge (with both an embedded cmdline and an
initrd bootconfig, early params reflect the embedded values because the initrd
isn't parsed yet) and leave the early-param-aware override detection as the
follow-up you describe.
Thanks for the documenting :)
quoted
(BTW, early parameter problem is a bit complicated. It is not hard
to distinguish early parameters, but kernel accepts the same key
for early parameter and normal parameter. e.g. "console=")
Right, console= being both is the awkward case. Agreed that's better as
its own series once we have a reliable way to detect early params.
So the v6 plan:
- rename CONFIG_BOOT_CONFIG_EMBED_CMDLINE -> CONFIG_CMDLINE_FROM_BOOTCONFIG
(or _BOOT_CONFIG, your call)
- make it mutually exclusive with CONFIG_CMDLINE (depends on CMDLINE = "")
- reframe the Kconfig help + bootconfig.rst as "CONFIG_CMDLINE from a
bootconfig file"
- keep (a): no rendering in /proc/bootconfig; document the early-param
sharp edge
- defer early-param-aware override detection to a follow-up
Thanks for the direction,
Thanks for working on this feature!
Thank you,
--breno
--
Masami Hiramatsu (Google) [off-list ref]