Re: [PATCH] ebpf: fix compatibility with libbpf 1.0+

[Shreesh Adiga <16567adigashreesh@gmail.com>]

On Mon, Dec 19, 2022 at 01:49:37PM +0000, Daniel P. Berrangé wrote:
> On Mon, Dec 19, 2022 at 07:14:54PM +0530, Shreesh Adiga wrote:
> > Hi Daniel,
> >
> > On Mon, Dec 19, 2022 at 10:56:57AM +0000, Daniel P. Berrangé wrote:
> > > On Sun, Dec 18, 2022 at 08:09:27PM +0530, Shreesh Adiga wrote:
> > > > The current implementation fails to load on a system with
> > > > libbpf 1.0 and reports that legacy map definitions in 'maps'
> > > > section are not supported by libbpf v1.0+. This commit updates
> > > > the Makefile to add BTF (-g flag) and appropriately updates
> > > > the maps in rss.bpf.c and update the skeleton file in repo.
> > >
> > > Can you split this into two pieces - one updating the build
> > > system for new compiler usage, and one updating the program
> > > to remove the legacy map defs.
> > >
> > If I just update the Makefile first, rss.bpf.c doesn't compile
> > and throws error:
> > rss.bpf.c:80:1: error: variable has incomplete type 'struct bpf_map_def'
> >
> > Similarly if first rss.bpf.c only is updated, then error is thrown:
> > libbpf: BTF is required, but is missing or corrupted
> > Hence, it would seem logical to update both of them together in same
> > commit.
> >
> > Do you mean first commit should update the Makefile and rss.bpf.c
> > together and second commit should be updating the rss.bpf.skeleton.h
> > file? I was under the impression that every commit should result in
> > compilable sources, hence wanted to clarify this.
>
> Yes, it must be compilable. I was under the impression from the
> commit that these were independant changes, but I was wrong.
>
Could you please confirm if the current single patch is good enough for
submission, or do I need to send a v2 series with changes split into
two commits, one for Makefile + rss.bpf.c and second one for skeleton
file update?

Thanks,
Shreesh