ACK: [SRU][BIONIC][PATCH v3 0/2] add bpftool to linux-tools-common

Seth Forshee seth.forshee at canonical.com
Tue Jan 21 20:11:44 UTC 2020


On Wed, Nov 20, 2019 at 11:48:19AM +0000, Quentin Monnet wrote:
> BugLink: https://bugs.launchpad.net/bugs/1774815
> 
> [Impact]
> 
> bpftool is a debugging and introspection tool for BPF elements,
> developed by the BPF kernel community. It is essential to list and dump
> BPF programs and maps loaded on the system. Its sources are located in
> the kernel repository, and because it is not packaged, administrators
> willing to use bpftool must download the whole kernel sources, compile
> and install the utility.
> 
> [Fix]
> 
> Adding bpftool to linux-tools and linux-tools-common packages makes it
> easily accessible. These packages are already used to provide other
> tools located in the kernel repository, such as perf.
> 
> The bpftool version provided with kernel 4.15 does not build properly,
> because the API changed at some point in bfd.h from binutils-dev. Also,
> it should be noted that the binutils-dev package description forbids
> dependencies on libbfd:
> 
>    This package includes header files and static libraries necessary to
>    build programs which use the GNU BFD library, which is part of
>    binutils.  Note that building Debian packages which depend on the
>    shared libbfd is Not Allowed.
> 
> Therefore, the proposed solution here is to get rid of the
> libbfd/binutils-dev dependency entirely. So far it was used by perf
> only, but perf can also be compiled without it anyway. Removing
> binutils-dev also avoids being locked to a specific libbfd version in
> case of future API changes.
> 
> This series contains four patches: the first to add feature detection to
> bpftool Makefile, the second to use those features and to leave out the
> bits relying on libbpfd. Then third patch removes dependency on
> binutils-dev for the Linux package. At last, fourth patch adds packaging
> for bpftool.
> 
> [Testcase]
> 
> A test linux package was successfully built, at:
> 
> https://launchpad.net/~qmonnet/+archive/ubuntu/ppa-linux-bpftool
> 
> (Built with:
>   do_zfs=false
>   do_dkms_nvidia=false
>   do_dkms_vbox=false
>   skipabi=true
>   skipmodule=true
>   skipretpoline=true)
> 
> Packages linux-tools-$(uname -r) and linux-tools-common can be built
> with "debian/rules binary", and contain bpftool's binary and related
> files (redirection script, bpftool manual pages, bash completion),
> respectively.
> 
> [Regression Potential]
> 
> Low, as far as I can tell:
> 
> - binutils-dev was only used for building perf, but it is not mandatory
>   and perf can be built without libbfd. The dependency on binutils-dev
>   has been successfully removed on eoan.
> 
> - The backported patches touch only bpftool and one feature in
>   tools/build/feature (only used with bpftool), all of it user space
>   tools not used for anything other than bpftool itself.
> 
> - bpftool packaging does not change the way other tools are packaged
>   (apart from creating $(toolsman)/man8 a few lines earlier), and should
>   have no impact on the packaging of other tools. One dependency is
>   added to Build-Depends-Indep.
> 
> ---
> Packaging for bpftool is upstream in eoan/master-next as commit 8579afd20b0c.
> 
> Discussion on v2 for bionic is available at:
> https://lists.ubuntu.com/archives/kernel-team/2019-October/104622.html
> 
> Changes in v3:
> - Remove dependency on libbpf (bintutils-dev package). This adds two
>   patches: one to actually remove the dependency, the other (backported)
>   to make bpftool build without libbfd. The commit fixing the build for
>   binutils >= 2.9, backported in the previous iteration to fix bpftool
>   compilation, is kept in this series because it adds feature detection
>   to bpftool Makefile (required to build without libbfd).
> 
> Changes in v2:
> - Patch has been applied to eoan.
> - Switch from python-docutils to python3-docutils for the dependency
>   providing rst2man for manual pages.
> - Set CROSS_COMPILE when building bpftool.
> 
> I have been away from work for some time, please accept my sincere
> apologies for the delay since v2 - especially because I chased up in the
> past to have the set reviewed.

And I apologize for not acking this sooneer, seems I missed it on the
list when it was sent.

Acked-by: Seth Forshee <seth.forshee at canonical.com>



More information about the kernel-team mailing list