On Wed, 4 Dec 2019 15:39:49 -0800 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> 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
