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

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

Hi Breno,

On Mon, 22 Jun 2026 05:30:53 -0700
Breno Leitao <leitao@debian.org> 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 <leitao@debian.org> 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/20260617-bootconfig_using_tools-v5-0-fd589a9cc5e3@debian.org
> 
> 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) <mhiramat@kernel.org>