On Wed, Sep 7, 2022 at 12:07 PM Stephen Brennan <stephen.s.brennan@xxxxxxxxxx> wrote: > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > > On Fri, Aug 26, 2022 at 11:54 AM Stephen Brennan > > <stephen.s.brennan@xxxxxxxxxx> wrote: > [...] > >> Future Work > >> ----------- > >> > >> If this proves acceptable, I'd like to follow-up with a kernel patch to > >> add a configuration option (default=n) for generating BTF with all > >> variables, which distributions could choose to enable or not. > >> > >> There was previous discussion[3] about leveraging split BTF or building > >> additional kernel modules to contain the extra variables. I believe with > >> this patch series, it is possible to do that. However, I'd argue that > >> simpler is better here: the advantage for using BTF is having it all > >> available in the kernel/module image. Storing extra BTF on the > >> filesystem would break that advantage, and at that point, you'd be > >> better off using a debuginfo format like CTF, which is lightweight and > >> expected to be found on the filesystem. > > > > With all or nothing approach the distros would have a hard choice > > to make whether to enable that kconfig, increase BTF and consume > > extra memory without any obvious reason or just don't do it. > > Majority probably is not going to enable it. > > So the feature will become a single vendor only and with > > inevitable bit-rot. > > I'd intend to support it even if just a single distribution enabled it. > But I do see your concern. This thread was dormant for 8 days. That's a poor example of "intend to support". > > Whereas with split BTF and extra kernel module approach > > we can enable BTF with all global vars by default. > > The extra module will be shipped by all distros and tools > > like bpftrace might start using it. > > Split BTF is currently limited to a single base BTF file. We'd need more > patches for pahole to support multiple --btf_base files: e.g. > vmlinux.btf and vmlinux-variables.btf. There's also the question of > modules: presumably we wouldn't try to have "$MODULE" and > "$MODULE-btf-extra" modules due to the added complexity. I doubt the > space savings would be worth it. > > I can look into these concerns, but if possible I would like to proceed > with this series, as it is a separate concern from the exact mechanism > by which we include extra BTF into the kernel. Not an option. Sorry.
