anakryiko / retsnoop

Investigate kernel error call stacks
BSD 2-Clause "Simplified" License
186 stars 32 forks source link

RFE: allow linking against system libraries and tools #22

Closed michel-slm closed 1 year ago

michel-slm commented 1 year ago

retsnoop currently bundles in libbpf and bpftool as submodules. Would it be possible to optionally use the system-packaged versions of libbpf and bpftool?

(Note: discussed with maintainer privately, but let's provide the rationale here for visibility)

anakryiko commented 1 year ago

I think it's totally fine and acceptable to allow external bpftool. I thought retsnoop's Makefile already allows that, but checking again, I think even if BPFTOOL is overridden, current Makefile will attempt to build bpftool from source. So we should fix that.

As for libbpf, it's a much harder sell and bigger developer productivity and maintainability cost. retsnoop often is using bleeding-edge features or fixes that might not be yet available in latest released libbpf version (and might not be for a while, given the speed at which libbpf package is updated across different distros varies wildly). Building and linking with precisely controlled libbpf is pretty essential for any modern BPF-based tool, and examples that tried to not do this (e.g., bpftrace, iproute2, systemd) have to pay the price of this with extra convoluted feature-detection and workaround code. So for the time being, I think retsnoop should control its own destiny and continue using libbpf built from submodule.