Hi Breno, On Mon, 22 Jun 2026 05:30:53 -0700 Breno Leitao <[email protected]> wrote:
> On Thu, Jun 18, 2026 at 09:47:19AM +0900, Masami Hiramatsu wrote: > > On Wed, 17 Jun 2026 02:56:23 -0700 > > Breno Leitao <[email protected]> wrote: > > > > > On Wed, Jun 10, 2026 at 07:58:10AM -0700, Breno Leitao wrote: > > > > On Wed, Jun 10, 2026 at 11:37:20PM +0900, Masami Hiramatsu wrote: > > > > > 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/[email protected] > > The naming/mutual-exclusion rework below I'll fold into v6. Yeah, thanks for updating! > > > 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. > > > 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. > > > 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. > > > 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. > > 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.) > > 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 :) > > > (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) <[email protected]>
