This series moves embedded bootconfig (CONFIG_BOOT_CONFIG_EMBED) parsing
before setup_arch() in start_kernel(). The goal is to prepare for a
follow-up change that will allow bootconfig to provide early_param()
parameters (e.g. memblock=debug, loglevel) that are consumed during
architecture-specific setup.

Currently, bootconfig depends on memblock for memory allocation, which
is not available until setup_arch() initializes it. This series removes
that dependency by replacing memblock allocations with static __initdata
buffers (~96KB total, freed after init), then splits the bootconfig
loading into an early embedded path and a late initrd path.

The static buffers are used by both the kernel and the userspace
tools/bootconfig parser, which simplifies the code by removing the

These patches alone do not change user-visible behavior. Bootconfig
parameters are still stored in extra_command_line, which gets merged
into boot_command_line by setup_command_line() after setup_arch().

Making parse_early_param() see bootconfig values during setup_arch()
is a separate change that will follow once this infrastructure is
accepted.

Keeping the two efforts separate simplifies review, since the
early_param() integration is a non-trivial change on its own.

Some discussion that led to this decision:

1) It is not trivial to parse early param after setup_arch()
https://lore.kernel.org/all/[email protected]/

2) An similar proposal from Petr 3 years ago:
https://lore.kernel.org/all/[email protected]/

---
Breno Leitao (3):
      bootconfig: use static buffers instead of memblock allocation
      init: use static buffers for bootconfig extra command line
      init: move embedded bootconfig parsing before setup_arch()

 init/main.c      | 91 +++++++++++++++++++++++++++++++++++++++++---------------
 lib/bootconfig.c | 56 +++++++---------------------------
 2 files changed, 77 insertions(+), 70 deletions(-)
---
base-commit: 1c7cc4904160c6fc6377564140062d68a3dc93a0
change-id: 20260414-bootconfig_earlier-9e185ceb71ae

Best regards,
--  
Breno Leitao <[email protected]>


Reply via email to