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

[Breno Leitao <leitao@debian.org>]

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.

> 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".

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.)

> 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)?

> 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.

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.

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

> 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

> 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.

> 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.

> (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,
--breno