Expand kconfig check to include more options, including device-specific kconfig

I've been thinking about how to ensure that there are no kconfig regressions across device kernels. Ideally kconfig fragments would be used so that it is easy to spot regressions in review, but I think that relying more on kconfig check in pmb might be good even if we have fragments support later on.

I'd like to get feedback on this, specifically:

1. continue to add more kconfig options that multiple kernels rely on, to the kconfig check, like I did in !2075 (merged), for nftables, and @minlexx did in !2060 (merged)

2. add a new mechanism to kconfig check that looks in the kernel package for a file like kconfig_required_options (or call it something better), which (if present) provides a list of required kconfig options for the kernel. This can be things like the wifi driver options, graphics options, input device driver options, etc.

3. Continue to run kconfig check on all kernels, including the kernel-specific check options from above

This wouldn't necessarily replace the need for kconfig fragment support, and could even be used to continue validating kernel config even after we eventually have fragments.

The goal is to prevent problems with rebasing config (which I do often on the L5 kernel... which is still seeing very active development) or making other changes to config where some required option might be accidentally disabled. Existing kconfig covers a lot, so this issue is really to get feedback on the above points and maybe formalize it since I think we're starting to use kconfig check more recently to do a lot of that (except the 2nd point since that required pmb changes).

added discussion kernel type::feature labels

continue to add more kconfig options that multiple kernels rely on, to the kconfig check, like I did in 2075, for nftables, and minlexx did in 2060 (merged)

Having many kconfig "options" might be useful for downstream kernels but I don't think we should use them for our close-to-mainline kernels. There should be no reason to keep functionality like containers or firewall disabled there. If we add more such options we should add something like a pmb:kconfigcheck-mainline option that enforces all of the optional options, so that all the close-to-mainline kernels have consistent functionality.

This will be rather annoying because several kernels need to be updated whenever adding new options, but that's exactly why we need the config fragment stuff so we can apply options automatically.

The kconfig checks (and a file like kconfig_required_options) are kind of just a limited variant of config fragments. You already have a list of the options you want to have set, but it's not specified in a format that can be also conveniently applied on top of an existing kernel config. So you have to go into the kernel config editor for each kernel and set everything manually.

The config fragments would combine both, you can apply it automatically and you can also easily parse it for validation. And actually scripts/kconfig/merge_config.sh (which is used for applying fragments) already complains about options that don't make it into the final config due to missing dependencies (although this could be made more obvious).

So, personally I don't think we should extend the kconfig functionality without keeping the config fragments in mind (which kind of requires finishing up discussion how to integrate them).

By Minecrell on 2021-06-24T11:00:31

There should be no reason to keep functionality like containers or firewall disabled there. If we add more such options we should add something like a pmb:kconfigcheck-mainline option that enforces all of the optional options, so that all the close-to-mainline kernels have consistent functionality.

1

By Alexey Min on 2021-06-24T17:00:49