Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

[Daniel Borkmann <daniel@iogearbox.net>]

On 12/18/2015 08:04 AM, Wangnan (F) wrote:
...
> What I want to do in this patchset is not only removing original libbpf.c
> and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
> available library for other userspace tools (tc for example).

Having this as a possible user space library seems fine.

Only speaking for the tc case specifically here (since you mention it as
one example), there's currently no additional value for it. The current
loader code there is functional and partially tailored for tc's needs and
having this together with the iproute2 repo, it allows us to easily change/
adapt the internal code whenever needed.

The only dependency the loader code has is that the BPF syscall got compiled
into the kernel and libelf, that's all. libelf is effectively available
in distros for more than a decade(s?). And iproute2 is being shipped
everywhere already as well (hence also iproute2's minimalism on library
dependencies).

Switching that code would mean that iproute2 would then depend on libbpf
which itself would depend on libelf, until every distro that ships iproute2
will also ship libbpf, it will take a bit. Changes on the code would then
need to go through libbpf first, and iproute2 would need to wait until it
becomes available to make use of it and probably need to implement some
compat code for the time being. Further, as both are decoupled also testing
effort increases to make sure nothing breaks among different versions.

That said, I prefer that tc's {cls,act}_bpf front-end is shipped to users
as it's being done already and that they can use it /now/ as-is. Don't get me
wrong, for other tools etc coming up in future, as mentioned, offering it as a
public library makes totally sense as not every application developer would
want to choose writing his own loader code.

Cheers,
Daniel