Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Wed, 4 Dec 2019 15:39:49 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Wed, Dec 04, 2019 at 01:54:05PM -0800, Jakub Kicinski wrote:
> > On Wed, 4 Dec 2019 13:16:13 -0800, Andrii Nakryiko wrote:  
> > > I wonder what big advantage having bpftool in libbpf's Github repo
> > > brings, actually? The reason we need libbpf on github is to allow
> > > other projects like pahole to be able to use libbpf from submodule.
> > > There is no such need for bpftool.
> > > 
> > > I agree about preference to release them in sync, but that could be
> > > easily done by releasing based on corresponding commits in github's
> > > libbpf repo and kernel repo. bpftool doesn't have to physically live
> > > next to libbpf on Github, does it?  
> > 
> > +1

I don't see any advantage of having bpftool in libbpf's GitHub repo.

As Jakub mention we have seen bpftool crash fixes, which would be
painful/annoying to maintain fixes for in the libbpf GitHub repo.

As Andrii also points out, it requires more work, as GitHub libbpf have
to maintain a separate Makefile for bpftool.


> > > Calling github repo a "mirror" is incorrect. It's not a 1:1 copy of
> > > files. We have a completely separate Makefile for libbpf, and we have
> > > a bunch of stuff we had to re-implement to detach libbpf code from
> > > kernel's non-UAPI headers. Doing this for bpftool as well seems like
> > > just more maintenance. Keeping github's Makefile in sync with kernel's
> > > Makefile (for libbpf) is PITA, I'd rather avoid similar pains for
> > > bpftool without a really good reason.  
> > 
> > Agreed. Having libbpf on GH is definitely useful today, but one can hope
> > a day will come when distroes will get up to speed on packaging libbpf,
> > and perhaps we can retire it? Maybe 2, 3 years from now? Putting
> > bpftool in the same boat is just more baggage.  
> 
> Distros should be packaging libbpf and bpftool from single repo on github.
> Kernel tree is for packaging kernel.

I don't think that is a good idea.  You are creating double work and
wasting distro developers time.  Let me explain: 

1. First of all, GitHub libbpf does not have a stable branches (which
makes sense, given this is a read-only clone of kernel tree). Thus,
distro developers have to maintain that themselves, in their internal
package tree (that is based on GitHub libbpf).

2. Kernel BPF changes usually require updates to libbpf, as selftests
uses libbpf.  Thus, the distro kernel backporter is already required to
backport libbpf parts.

This is double work, the code changes to libbpf are now maintained in
two places for the distro.


The disadvantage for distros to package libbpf (+ bpftool and perf) off
their distro kernel tree is that a fix to libbpf, requires rolling a
new kernel minor release.  The solution to that is simply that distro
package for libbpf have a separate (RPM) spec file, with own
versioning, which sources points to distro kernel tree.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer