Re: [PATCH bpf-next 1/3] selftests/bpf: Copy over libbpf configs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks,
Daniel

[0] https://lwn.net/Articles/397363/



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux