[PATCH bpf-next v3 0/3] Annotate kfuncs in .BTF_ids section

[Daniel Xu]

Hi Jiri,

On Sat, Jan 13, 2024 at 02:57:40PM +0100, Jiri Olsa wrote:
> On Fri, Jan 12, 2024 at 01:03:59PM -0700, Daniel Xu wrote:
> > On Fri, Jan 12, 2024 at 05:20:39PM +0100, Jiri Olsa wrote:
> > > On Sat, Jan 06, 2024 at 11:24:07AM -0700, Daniel Xu wrote:
> > > > === Description ===
> > > > 
> > > > This is a bpf-treewide change that annotates all kfuncs as such inside
> > > > .BTF_ids. This annotation eventually allows us to automatically generate
> > > > kfunc prototypes from bpftool.
> > > > 
> > > > We store this metadata inside a yet-unused flags field inside struct
> > > > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> > > > 
> > > > More details about the full chain of events are available in commit 3's
> > > > description.
> > > > 
> > > > The accompanying pahole changes (still needs some cleanup) can be viewed
> > > > here on this "frozen" branch [0].
> > > 
> > > so the plan is to have bpftool support to generate header file
> > > with detected kfuncs?
> > 
> > Yep, that's the major use case. But I see other use cases as well like
> 
> ok, any chance you could already include it in the patchset?
> would be a great way to test this.. maybe we could change
> selftests to use that

I haven't start working on that code yet, but I can.

Here is my plan FWIW:

1. Bump minimum required pahole version up. Or feature probe for
   kfunc decl tag support. Whatever is the standard practice here.

2. Teach bpftool to dump kfunc prototypes, guarded behind a flag.

3. Flip bpftool flag on in selftest build and remove all manual kfunc
   prototypes atomically in 1 commit.

I thought it'd be nicer to do it incrementally given all the moving
pieces. But if we want to land it all at once that is ok by me too.

Thanks,
Daniel