On Thu, Nov 08, 2018 at 11:51:22AM -0800, Laura Abbott wrote: > On 11/8/18 7:48 AM, Jakub Kicinski wrote: > > On Thu, 8 Nov 2018 14:37:54 +0100, Jesper Dangaard Brouer wrote: > > > Hi Jakub, Laura and Jiri Olsa (Cc others), > > > > > > Subj: iovisor-dev] minutes: IO Visor TSC/Dev Meeting > > > (To: iovisor-dev <iovisor-dev@lists.iovisor.org>) > > > On Wed, 31 Oct 2018 14:30:25 -0700 "Brenden Blanco" <bbla...@gmail.com> > > > wrote: > > > > Jakub: > > > > * working on getting libbpf packaged separately and released by distros > > > > * FB has external mirror github.com/libbpf/libbpf > > > > > > I noticed from the iovisor-dev minutes that you have plans for > > > packaging libbpf from the kernel tree. And via that I noticed the > > > github repo https://github.com/libbpf/libbpf, created by Yonghong Song. > > > > > > I'm uncertain if it makes sense to maintain this library outside the > > > kernel git tree?!? > > > > To my understanding it's useful in two ways: > > - some less fortunate distros (Debian) reportedly need a kernel build > > to package bpftool, and for libbpf the same would have to happen. > > At least that's what I'm told. So separate repo helps there a lot; > > - we actually use the separate git repo as a submodule in our projects > > (https://github.com/Netronome/bpf-samples will migrate there really > > soon, just finishing code review). > > > > So for us the git submodule thing works quite well until distros > > package libbpf :) > > >> To be honest, I have very little knowledge about building RPMs and > > > other packages formats. I just wanted to point out that RHEL and > > > Fedora is now shipping bpftool, which also part of kernel git tree. > > > > > > (Now I need input from Jiri Olsa and Laura to correct below statements:) > > > > > > AFAIK bpftool RPM-package[1] is part of the "Source Package" > > > kernel-tools, which AFAIK gets build directly from the distro kernel > > > git tree via kernel.spec file. This also happens for perf > > > RPM-package[2] see section "Source Package" also point to kernel-tools. > > > > > > So, my question is, can we ship/package libbpf in the same way? > > > > > > > > > Notice, that an increasing number of tools are linking/using libbpf, > > > e.g. perf, bpftool, Suricata, (selftests and samples/bpf). > > > > > > > > > [1] > > > https://fedora.pkgs.org/28/fedora-x86_64/bpftool-4.16.0-1.fc28.x86_64.rpm.html > > > [2] > > > https://fedora.pkgs.org/29/fedora-x86_64/perf-4.18.10-300.fc29.x86_64.rpm.html > > > > We were planning to do the same thing for libbpf. Let me copy paste the > > patch to the package: > > > > Add libbpf to kernel tools development libs. This library contains > > functionality for loading and managing eBPF programs. > > > > Signed-off-by: David Beckett <david.beck...@netronome.com> > > --- > > kernel-tools.spec | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/kernel-tools.spec b/kernel-tools.spec > > index 44d29ba..cf2f7a0 100644 > > --- a/kernel-tools.spec > > +++ b/kernel-tools.spec > > @@ -261,6 +261,9 @@ popd > > pushd tools/gpio/ > > make > > popd > > +pushd tools/lib/bpf > > +make > > +popd > > pushd tools/bpf/bpftool > > make > > popd > > @@ -347,6 +350,9 @@ popd > > pushd tools/kvm/kvm_stat > > make INSTALL_ROOT=%{buildroot} install-tools > > popd > > +pushd tools/lib/bpf > > +make DESTDIR=%{buildroot} prefix=%{_prefix} install install_headers > > +popd > > pushd tools/bpf/bpftool > > make DESTDIR=%{buildroot} prefix=%{_prefix} > > bash_compdir=%{_sysconfdir}/bash_completion.d/ mandir=%{_mandir} install > > doc-install > > popd > > @@ -420,8 +426,13 @@ popd > > %files -n kernel-tools-libs-devel > > %{_libdir}/libcpupower.so > > +%{_libdir}/libbpf.a > > +%{_libdir}/libbpf.so > > %{_includedir}/cpufreq.h > > %{_includedir}/cpuidle.h > > +%{_includedir}/bpf/bpf.h > > +%{_includedir}/bpf/btf.h > > +%{_includedir}/bpf/libbpf.h > > %files -n bpftool > > %{_sbindir}/bpftool > > > > Fairly trivial patch, but since we learnt about the separate repo we > > are migrating our internal projects and tests to that, then Alexei > > suggested we need to add proper versioning to libbpf, and when all that > > is done we can come back to packaging. > > > > Yes, this looks almost exactly like what I would expect to package > libpf. Fedora split out kernel-tools from the main kernel package > to reduce build dependencies (if something in kernel-tools breaks > it was blocking the build of the main kernel). I'm in favor of > continuing to move userspace tools out of the main kernel tree > for ease of packaging.
I think we're all on the same page. Just to reiterate few points: The source of truth of libbpf is in the kernel tree. github/libbpf is a mirror of kernel sources plus few headers that neceesary for the build. Currently we don't have the mirror automated, but the plan is to pull from the kernel tree continuously. .spec files can live in github too, and packages can be built out of it. When we were talking to distor folks they suggested to make sure that libbpf.SO have versioned symbols from day one. As far as I know that's the only thing blocking creation of official libbpf package. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1521): https://lists.iovisor.org/g/iovisor-dev/message/1521 Mute This Topic: https://lists.iovisor.org/mt/28036138/21656 Group Owner: iovisor-dev+ow...@lists.iovisor.org Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
