Closed michel-slm closed 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.
retsnoop
currently bundles inlibbpf
andbpftool
as submodules. Would it be possible to optionally use the system-packaged versions oflibbpf
andbpftool
?(Note: discussed with maintainer privately, but let's provide the rationale here for visibility)