On Mon, 30 Mar 2026 08:04:23 -0700
Breno Leitao [off-list ref] wrote:

On Mon, Mar 30, 2026 at 06:15:17AM -0700, Breno Leitao wrote:

quoted

On Fri, Mar 27, 2026 at 10:37:44PM +0900, Masami Hiramatsu wrote:

quoted

On Fri, 27 Mar 2026 03:06:41 -0700
Breno Leitao [off-list ref] wrote:

quoted

quoted

quoted

To fix this, we need to change setup_arch() for each architecture so
that it calls this bootconfig_apply_early_params().

Could we instead integrate this into parse_early_param() itself? That
approach would avoid the need to modify each architecture individually.

Ah, indeed.

I investigated integrating bootconfig into parse_early_param() and hit a
blocker: xbc_init() and xbc_make_cmdline() depend on memblock_alloc(), but on
most architectures (x86, arm64, arm, s390, riscv) parse_early_param() is called
from setup_arch() _before_ memblock is initialized.

That said, I'd like to propose a simpler approach as a first step:

1) Keep calling bootconfig_apply_early_params() from setup_boot_config().
   This is the least intrusive approach and expands bootconfig support to
   additional early boot parameters.

2) Document that architecture-specific early parameters might be ignored.
   If a parameter is consumed early enough (during setup_arch()), it will
   not see the bootconfig value.

We have to carefully do this because what parameter is arch specific or not
depends on architecture and undocumented.

How about introducing a new Kconfig, which supports early params by
embedded bootconfig?

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.

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.

If that is OK, that is what I have right now:

Let me comment on it.

This is easy to explain, but it's quite troublesome for users to
determine which parameters are unavailable. 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 :))

As a compromise, how about making this a separate Kconfig?

config BOOT_CONFIG_EMBED_EARLY_PARAM
	bool "Support early_params in embedded bootconfig"

and afterwards, we can introduce 

	depends on ARCH_BOOT_CONFIG_EMBED_EARLY_PARAM


Thank you,

-- 
Masami Hiramatsu (Google) [off-list ref]