On Thu, Oct 24, 2024 at 7:10 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > hey Andrii > > On 23/10/2024 01:08, Andrii Nakryiko wrote: > > Hey Alan, > > > > There were a few BTF-related features you've been working on, and I > > realized recently that I don't remember exactly where we ended up with > > them and whether there is anything blocking those features. So instead > > of going on a mailing list archeology trip, I decided to lazily ask > > you directly :) > > > > Basically, at some point we were discussing and reviewing BTF > > extensions to have a minimal description of BTF types sizes (fixed and > > per-item length). What happened to it? Did we decide it's not > > necessary, or is it still in the works? > > Yeah, it's still in the works; more on that below.. > > > > > Also, distilled BTF stuff. We landed libbpf-side API (and I believe > > the kernel-side changes went in as well, right?), but I don't think we > > enabled this functionality for kernel builds, is that right? What's > > missing to have relocatable BTF inside kernel modules? Pahole changes? > > Has that landed? > > > > The pahole changes are in, and will be available in the imminent v1.28 > release. Distilled BTF will however only be generated for out-of-tree > module builds, since it's not needed for kernels where vmlinux + module > are built at the same time. It's not, strictly speaking, needed, but it might be a good thing to do this anyways to avoid unnecessary rebuilding of kernel modules (always a good thing). But at the very least we should enable it for bpf_testmod* in BPF selftests. Can we start with that? > > Here's the set of BTF things I think we've discussed and folks have > talked about wanting. I've tried to order them based upon dependencies, > but in most cases a different ordering is possible. > > 1. Build vmlinux BTF as a module (support CONFIG_DEBUG_INFO_BTF=m). This > one helps the embedded folks as modules can be on a separate partition, > and a very large vmlinux is a problem in that environment apparently. > Plus we can do module compression, and I did some measurements and > vmlinux BTF shrinks from ~7Mb to ~1.5Mb when gzip-compressed. This is > sort of a dependency for > > 2. all global variables in BTF. Stephen Brennan added support to pahole, > but we haven't switched the feature on yet in Makefile.btf. Needs more > testing and for some folks the growth in vmlinux BTF (~1.5Mb) may be an > issue, hence a soft dependency on 1. > > 3. BTF header modifications to support kind layout. I've been waiting > for the need for a new BTF kind to add this, but that's not strictly > needed. But that brings us on to > > 4. Augmenting BTF representations to support site-specific info > (including function addresses). We talked about this a bit with Yonghong > at plumbers. Will probably require new kind(s) so 3 should likely be > done first. May also need some special handling so as not to expose > function addresses to unprivileged users. > > So I think 1 is possibly needed before 2, and I'm working on an RFC for > 1 which I hope to get sent out next week (been a bit delayed working on > the pahole release). 3 would need to be done before 4, or ideally any > other series that introduced new BTF kinds. > > So that's the set of things I'm aware of - there may be other needs of > course - but the order 1-4 was roughly how I was thinking we could > attack it. 1 and 2 don't require core BTF changes, so are less > disruptive. We'd got pretty far down the road with an earlier version of > 3, so if anyone needed it sooner than I get to it, I'd be happy to help > of course. Thanks, Alan, for the list. I think we should prioritize 3 (and 1, of course), as you said, any BTF extension would be blocked on this (as far as I'm concerned at least). I wouldn't delay until we actually add a new BTF kind to land BTF header modifications, that would just delay future work unnecessarily. > > Thanks! > > Alan >
