hello Masami,
On Tue, Mar 31, 2026 at 12:58:27PM +0900, Masami Hiramatsu wrote:
> > 3) Ensure that early bootconfig parameters don't overwrite the boot command
> > line. For example, if the boot command line has foo=bar and bootconfig
> > later has foo=baz, the command line value should take precedence.
> > This prevents early boot code (in setup_arch()) from seeing a parameter
> > value that will be changed later.
>
> OK, this also needs to be considered. Currently we just pass the bootconfig
> parameters right before bootloader given parameters as "extra_command_line"
> if "bootconfig" in cmdline or CONFIG_BOOT_CONFIG_FORCE=y.
>
> [boot_config(.kernel)]<command_line>[ --
> [boot_config(.init)][init_command_line]]
>
> This is currently expected behavior. The bootconfig parameters are
> expected to be overridden by command_line or command_line are appended.
That's correct, and I have no intention of changing this behavior. Here's
the current approach:
1) Early parameters from the bootloader are parsed first in setup_arch()
2) Subsequently, bootconfig_apply_early_params() is invoked. Any early
parameter that was already parsed from the bootloader (in setup_arch())
will be skipped at this stage.
> If we change this for early params, we also should change the expected
> output of /proc/cmdline too. I think we have 2 options;
>
> - As before, we expect the parameters provided by the boot configuration
> to be processed first and then overridden later by the command line.
>
> Or,
>
> - ignore all parameters which is given from the command line, this also
> updates existing setup_boot_config() (means xbc_snprint_cmdline() ).
>
> Anyway, this behavior change will also be a bit critical... We have
> to announce it.
As mentioned above, I don't anticipate any changes to existing behavior.
Bootconfig parsing remains unchanged. The only modification is that
bootconfig_apply_early_params() will skip any early config parameter
that's already present in the bootloader command line.
> > +Note that embedded bootconfig is parsed after ``setup_arch()``, so
> > +early options that are consumed during architecture initialization
> > +(e.g., ``mem=``, ``memmap=``, ``earlycon``, ``noapic``, ``nolapic``,
> > +``acpi=``, ``numa=``, ``iommu=``) may not take effect from bootconfig.
> > +
>
> This is easy to explain, but it's quite troublesome for users to
> determine which parameters are unavailable.
Agreed. This turned out to be significantly more complex than I
initially anticipated.
I'm uncertain whether we can accomplish this without examining every
early_parameter() implementation in depth.
> Currently we can identify
> it by `git grep early_param -- arch/${ARCH}`. But it is setup in
> setup_arch() we need to track the source code. (Or ask AI :))
The challenge extends beyond that. There are numerous early_parameter()
definitions scattered throughout the kernel that may or may not be
utilized by setup_arch().
For example, consider `early_param("mitigations", ..)` in
./kernel/cpu.c. This modifies the cpu_mitigations global variable, which
is referenced in various locations across different architectures.
It's worth noting that we have over 300 early_parameter() instances in
the kernel.
Given this, analyzing all these early parameters and examining each one
individually represents a substantial amount of work.
Are there alternative approaches? At this point, I'm leaning toward
breaking bootconfig's dependency on memblock, allowing us to invoke it
before setup_arch(). Is this the only practical solution available?!
Thanks,
--breno
