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

[Michael Ellerman]

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