Kees Cook <keescook@xxxxxxxxxxxx> 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
