Re: [PATCH] kbuild: Show Kconfig fragments in "help"

Michael Ellerman
2023-08-25T06:12:56Z

Kees Cook <keescook@chromium.org> writes:
> Doing a "make help" would show only hard-coded Kconfig targets and
> depended on the archhelp target to include ".config" targets. There was
> nothing showing global kernel/configs/ targets. Solve this by walking
> the wildcard list and include them in the output, using the first comment
> line as the help text.
>
> Update all Kconfig fragments to include help text and adjust archhelp
> targets to avoid redundancy.
>
> Adds the following section to "help" target output:
>
> Configuration fragment targets (for enabling various Kconfig items):
> debug.config - Debugging for CI systems and finding regressions
> kvm_guest.config - Bootable as a KVM guest
> nopm.config - Disable Power Management
> rust.config - Enable Rust
> tiny-base.config - Minimal options for tiny systems
> tiny.config - Smallest possible kernel image
> x86_debug.config - Debugging options for tip tree testing
> xen.config - Bootable as a Xen guest
> tiny.config - x86-specific options for a small kernel image
> xen.config - x86-specific options for a Xen virtualization guest

I think we need a way to opt some files out.

It's a bit ugly on powerpc because there are so many fragments:

Configuration fragment targets (for enabling various Kconfig items):
debug.config - Debugging for CI systems and finding regressions
kvm_guest.config - Bootable as a KVM guest
nopm.config - Disable Power Management
rust.config - Enable Rust
tiny-base.config - Minimal options for tiny systems
tiny.config - Smallest possible kernel image
x86_debug.config - Debugging options for tip tree testing
xen.config - Bootable as a Xen guest
32-bit.config - Build a 32-bit image
64-bit.config - Build a 64-bit image
85xx-32bit.config - Build a 32-bit 85xx image
85xx-64bit.config - Build a 64-bit 85xx image
85xx-hw.config - Base hardware support for 86xx
85xx-smp.config - Enable SMP on 85xx
86xx-hw.config - Base hardware support for 86xx
86xx-smp.config - Enable SMP on 86xx
altivec.config - Enable Altivec support
be.config - Enable Big Endian mode
book3s_32.config - Base support for Book3s
corenet_base.config - Base support for corenet
debug.config - Enable PowerPC specific debug options
disable-werror.config - Disable -Werror
dpaa.config - Base suppot for DPPA
fsl-emb-nonhw.config - Non-hardware options common to 85xx and corenet
guest.config - PowerPC specific virtualization guest options
kvm_guest.config - Bootable as a KVM guest
le.config - Enable Little Endian mode
mpc85xx_base.config - Base mpc85xxx support
mpc86xx_base.config - Base mpc85xxx support
ppc64le.config - Enable ppc64le mode
security.config - Common security options for PowerPC builds

And some of those are not intended for use with "make foo.config",
they're used internally for generating our "normal" defconfigs and they
don't necessarily work on their own.

Also I'd like to add more fragments in future, to the point where nearly
all our configs are generated by them.

Can we have some way to differentiate fragments that are intended to be
used with "make foo.config" vs just being used internally to generate
other configs.

The obvious thing would be to use a different suffix, eg. "foo.fragment"
for internal use fragments. That would require changing
merge_into_defconfig and merge_into_defconfig_override to not assume the
.config suffix, and update the users in arm, arm64 and powerpc.

The other option would be to ignore .config files starting with eg. "_".

+ @$(foreach c, $(filter-out $(call configfiles,_*.config),$(call configfiles,*.config)), \
+ printf " %-20s - %s\\n" \
+ $(shell basename $(c)) \
+ "$(subst # ,,$(shell grep -m1 '^# ' $(c)))";)

Not sure which is preferable.

cheers