On Tue, Jul 12, 2022 at 11:01:38PM +0000, Daniel Müller wrote: > On Tue, Jul 12, 2022 at 03:33:26PM -0700, sdf@xxxxxxxxxx wrote: > > On 07/12, Daniel M�ller wrote: > > > On Tue, Jul 12, 2022 at 02:27:47PM -0700, Alexei Starovoitov wrote: > > > > On Tue, Jul 12, 2022 at 2:21 PM Daniel M�ller <deso@xxxxxxxxxx> wrote: > > > > > > > > > > This change integrates the libbpf maintained configurations and > > > > > black/white lists [0] into the repository, co-located with the BPF > > > > > selftests themselves. The only differences from the source is that we > > > > > replaced the terms blacklist & whitelist with denylist and allowlist, > > > > > respectively. > > > > > > > > > > [0] https://github.com/libbpf/libbpf/tree/20f03302350a4143825cedcbd210c4d7112c1898/travis-ci/vmtest/configs > > > > > > > > > > Signed-off-by: Daniel M�ller <deso@xxxxxxxxxx> > > > > > --- > > > > > .../bpf/configs/allowlist/ALLOWLIST-4.9.0 | 8 + > > > > > .../bpf/configs/allowlist/ALLOWLIST-5.5.0 | 55 + > > > > > .../selftests/bpf/configs/config-latest.s390x | 2711 +++++++++++++++ > > > > > .../bpf/configs/config-latest.x86_64 | 3073 > > > +++++++++++++++++ > > > > > > > > Instead of checking in the full config please trim it to > > > > relevant dependencies like existing selftests/bpf/config. > > > > Otherwise every update/addition would trigger massive patches. > > > > > Thanks for taking a look. Sure. Do we have some kind of tooling for that > > > or are > > > there any suggestions on the best approach to minimize? > > > > I would be interested to know as well if somebody knows some tricks on > > how to deal with kconfig. I've spent some time yesterday manually > > crafting various minimal bpf configs (for build tests), running make > > olddefconfig and then verifying that all my options are still present in > > the final config file. > > > > It seems like kconfig tool can resolve some of the dependencies, > > but there is a lot of if/endif that can break in non-obvious ways. > > For example, putting CONFIG_TRACING=y and doing 'make olddefconfig' > > won't get you CONFIG_TRACING=y in the final .config > > > > So the only thing, for me, that helped, was to manually go through > > the kconfig files trying to see what the dependencies are. > > I've tried scripts/kconfig/merge_config.sh, but it doesn't > > seem to bring anything new to the table.. > > > > So here is what I ended up with, I don't think it will help you that > > much, but at least can highlight the moving parts (I was thinking that > > maybe we can eventually put them in the CI as well to make sure all weird > > configurations are build-tested?): > > [...] > > I *think* that make savedefconfig [0] is the way to go, at least for my use > case. That cuts down the config file to <350 lines. However, it does change some > configurations from 'm' to 'y', which I can't say I quite understand or would > have expected (but perhaps minimal implies no modules or similar; I haven't > investigated). > I am still verifying that the result is working as expected, though. Just to add to that...it turns out that while savedefconfig works, it can produce faulty configs by silently disabling functionality when used with an architecture that is not the native one (i.e., make ARCH=xxx savedefconfig). The reason being that some options may directly or indirectly dependent on the compiler supporting certain features. But if one "just" wants to minimize a configuration for a different architecture, a fully blown cross-compilation toolchain may not be present. So the feature availability check fails and, consequently, options may be disabled. That so happened in my case where we want to have a config for s390. I noticed that BPF_JIT (which was set in the to-be-minimized config), for example, always ended up being disabled. The reason turned out to be that it transitively depends on MARCH_Z196 which "depends on $(cc-option,-march=z196)", which, well, my compiler does not know about. I am unsure if there is a better way than to manually fiddle around to get those options back or whether I was using it wrong. I also have not come across any warnings about such behavior, but perhaps I missed it; or it's "too obvious". Daniel
