Re: [PATCH 5/8] kconfig: Add support for merging defconfig fragments

Daniel Gomez <[email protected]> Sun, 7 Dec 2025 21:37:39 +0100
Newsgroups dev.linux.lists.kdevops
Organization kernel.org
Message-ID <[email protected]>
On 06/12/2025 17.56, Luis Chamberlain wrote:
> Add support for composing defconfigs from base configurations and
> fragments using the + syntax. This allows users to combine a base
> defconfig with additional config fragments stored in defconfigs/configs/.
> 
> The merge_config.sh script from the kernel is used to combine the
> configurations. Multiple fragments can be chained together.
> 
> Example usage:
>   make defconfig-datacrunch-b200-or-less+myworkflow
>   make defconfig-aws+fstests+debug
> 
> This enables modular configuration management where common settings
> can be shared across different base configurations.

As a user of fragments for both kernel and kdevops, I think this is handy
for upstream kernel too.

The only difference in the way I use fragments is that for kernel configs
I always start from scratch while for kdevops I always start with a defconfig.

My kernel config step starts with:

./scripts/kconfig/merge_config.sh \
-n \
.config \
fragment1.config fragment2.config

make -j$(nproc)

For kdevops I always do:

make defconfig-<config>
./scripts/kconfig/merge_config.sh \
-n \
.config \
fragment1.config fragment2.config

Not sure if users could simply do:
make +fragment1+fragment2

> 
> Generated-by: Claude AI
> Signed-off-by: Luis Chamberlain <[email protected]>
> ---
>  scripts/kconfig/kconfig.Makefile | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/kconfig/kconfig.Makefile b/scripts/kconfig/kconfig.Makefile
> index 5d6db4b8..0113ffd3 100644
> --- a/scripts/kconfig/kconfig.Makefile
> +++ b/scripts/kconfig/kconfig.Makefile
> @@ -57,7 +57,25 @@ PHONY += $(simple-targets)
>  $(simple-targets): $(KCONFIG_DIR)/conf Kconfig
>  	$< --$@ Kconfig
>  
> +# Support merging config fragments with base defconfigs
> +# Usage: make defconfig-<base>+<fragment>
> +# Example: make defconfig-datacrunch-b200-or-less+myworkflow
> +#
> +# The fragment is looked up in defconfigs/configs/<fragment>.config
> +# Multiple fragments can be chained: make defconfig-base+frag1+frag2
>  defconfig-%:: $(KCONFIG_DIR)/conf include/config/project.release Kconfig
> -	@$< --defconfig=defconfigs/$(@:defconfig-%=%) Kconfig
> +	@STEM="$(@:defconfig-%=%)"; \
> +	if echo "$$STEM" | grep -q '+'; then \
> +		BASE=$$(echo "$$STEM" | cut -d'+' -f1); \
> +		FRAGS=$$(echo "$$STEM" | cut -d'+' -f2- | tr '+' ' '); \
> +		FRAG_FILES=""; \
> +		for f in $$FRAGS; do \
> +			FRAG_FILES="$$FRAG_FILES defconfigs/configs/$$f.config"; \
> +		done; \
> +		$(KCONFIG_DIR)/merge_config.sh -m -Q defconfigs/$$BASE $$FRAG_FILES && \
> +		$< --defconfig=.config Kconfig; \

This command only merges/combines the fragments into the target .config.

  -m    only merge the fragments, do not execute the make command

I normally run it with -n (see above) to validate the final .config with
allnoconfig:

  -n    use allnoconfig instead of alldefconfig

I think we need here too. Or why is not needed in this case?

It would also be useful to support out-of-tree configs. For example, I keep some
for PCIe passthrough devices and workflow setups with device-specific names,
along with a few other local (not generic) settings.

> +	else \
> +		$< --defconfig=defconfigs/$$STEM Kconfig; \
> +	fi
>  
>  .PHONY: $(PHONY)