On Wed, Nov 27, 2019 at 10:22:31PM +0100, Daniel Borkmann wrote: > On 11/27/19 9:24 PM, Andrii Nakryiko wrote: > > On Wed, Nov 27, 2019 at 8:38 AM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > On Wed, Nov 27, 2019 at 1:48 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > > > > > hi, > > > > adding support to link bpftool with libbpf dynamically, > > > > and config change for perf. > > > > > > > > It's now possible to use: > > > > $ make -C tools/bpf/bpftool/ LIBBPF_DYNAMIC=1 > > > > > > > > which will detect libbpf devel package with needed version, > > > > and if found, link it with bpftool. > > > > > > > > It's possible to use arbitrary installed libbpf: > > > > $ make -C tools/bpf/bpftool/ LIBBPF_DYNAMIC=1 LIBBPF_DIR=/tmp/libbpf/ > > > > > > > > I based this change on top of Arnaldo's perf/core, because > > > > it contains libbpf feature detection code as dependency. > > > > It's now also synced with latest bpf-next, so Toke's change > > > > applies correctly. > > > > > > I don't like it. > > > Especially Toke's patch to expose netlink as public and stable libbpf api. > > > bpftools needs to stay tightly coupled with libbpf (and statically > > > linked for that reason). > > > Otherwise libbpf will grow a ton of public api that would have to be stable > > > and will quickly become a burden. > > +1, and would also be out of scope from a BPF library point of view. ok, static it is.. ;-) thanks for the feedback, jirka > > > I second that. I'm currently working on adding few more APIs that I'd > > like to keep unstable for a while, until we have enough real-world > > usage (and feedback) accumulated, before we stabilize them. With > > LIBBPF_API and a promise of stable API, we are going to over-stress > > and over-design APIs, potentially making them either too generic and > > bloated, or too limited (and thus become deprecated almost at > > inception time). I'd like to take that pressure off for a super-new > > and in flux APIs and not hamper the progress. > > > > I'm thinking of splitting off those non-stable, sort-of-internal APIs > > into separate libbpf-experimental.h (or whatever name makes sense), > > and let those be used only by tools like bpftool, which are only ever > > statically link against libbpf and are ok with occasional changes to > > those APIs (which we'll obviously fix in bpftool as well). Pahole > > seems like another candidate that fits this bill and we might expose > > some stuff early on to it, if it provides tangible benefits (e.g., BTF > > dedup speeds ups, etc). > > > > Then as APIs mature, we might decide to move them into libbpf.h with > > LIBBPF_API slapped onto them. Any objections? > > I don't think adding yet another libbpf_experimental.h makes sense, it feels > too much of an invitation to add all sort of random stuff in there. We already > do have libbpf.h and libbpf_internal.h, so everything that does not relate to > the /stable and public/ API should be moved from libbpf.h into libbpf_internal.h > such as the netlink helpers, as one example, and bpftool can use these since > in-tree changes also cover the latter just fine. So overall, same page, just > reuse/improve libbpf_internal.h instead of a new libbpf_experimental.h. > > Thanks, > Daniel >
