Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Quentin Monnet <quentin@isovalent.com> To: Andrii Nakryiko <andrii.nakryiko@gmail.com> Cc: Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org> Subject: Re: [PATCH bpf-next v3 0/8] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF Date: Fri, 30 Jul 2021 21:23:02 +0100 [thread overview] Message-ID: <CACdoK4KCbseLYzY2aqVM5KC0oXOwzE-5b3-g07uoeyJN4+r70g@mail.gmail.com> (raw) In-Reply-To: <CAEf4BzbjN+zjio3HPRkGLRgZpbLj9MUGLnXt1KDSsoOHB8_v3Q@mail.gmail.com> On Fri, 30 Jul 2021 at 18:24, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote: [...] > > > The right approach will be to define > > > LIBBPF_MAJOR_VERSION/LIBBPF_MINOR_VERSION in some sort of > > > auto-generated header, included from libbpf_common.h and installed as > > > part of libbpf package. > > > > So generating this header is easy. Installing it with the other headers > > is simple too. It becomes a bit trickier when we build outside of the > > directory (it seems I need to pass -I$(OUTPUT) to build libbpf). > > Not sure why using the header is tricky. We auto-generate > bpf_helper_defs.h, which is included from bpf_helpers.h, which is > included in every single libbpf-using application. Works good with no > extra magic. bpf_helper_defs.h is the first thing I looked at, and I processed libbpf_version.h just like it. But there is a difference: bpf_helper_defs.h is _not_ included in libbpf itself, nor is it needed in bpftool at the bootstrap stage (it is only included from the eBPF skeletons for profiling or showing PIDs etc., which are compiled after libbpf). The version header is needed in both cases. > > > > > The step I'm most struggling with at the moment is bpftool, which > > bootstraps a first version of itself before building libbpf, by looking > > at the headers directly in libbpf's directory. It means that the > > generated header with the version number has not yet been generated. Do > > you think it is worth changing bpftool's build steps to implement this > > deprecation helper? > > If it doesn't do that already, bpftool should do `make install` for > libbpf, not just build. Install will put all the headers, generated or > otherwise, into a designated destination folder, which should be > passed as -I parameter. But that should be already happening due to > bpf_helper_defs.h. bpftool does not run "make install". It compiles libbpf passing "OUTPUT=$(LIBBPF_OUTPUT)", sets LIBBPF_PATH to the same directory, and then adds "-I$(LIBBPF_PATH)" for accessing bpf_helper_defs.h and compile its eBPF programs. It is possible to include libbpf_version.h the same way, but only after libbpf has been compiled, after the bootstrap. I'll look into updating the Makefile to compile and install libbpf before the bootstrap, when I have some time.
next prev parent reply other threads:[~2021-07-30 20:23 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-29 16:20 [PATCH bpf-next v3 0/8] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 1/8] libbpf: return non-null error on failures in libbpf_find_prog_btf_id() Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 2/8] libbpf: rename btf__load() as btf__load_into_kernel() Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 3/8] libbpf: rename btf__get_from_id() as btf__load_from_kernel_by_id() Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 4/8] tools: free BTF objects at various locations Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 5/8] tools: replace btf__get_from_id() with btf__load_from_kernel_by_id() Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 6/8] libbpf: prepare deprecation of btf__get_from_id(), btf__load() Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 7/8] libbpf: add split BTF support for btf__load_from_kernel_by_id() Quentin Monnet 2021-07-29 16:20 ` [PATCH bpf-next v3 8/8] tools: bpftool: support dumping split BTF by id Quentin Monnet 2021-07-30 0:31 ` [PATCH bpf-next v3 0/8] libbpf: rename btf__get_from_id() and btf__load() APIs, support split BTF Andrii Nakryiko 2021-07-30 15:23 ` Quentin Monnet 2021-07-30 17:24 ` Andrii Nakryiko 2021-07-30 20:23 ` Quentin Monnet [this message] 2021-07-30 21:54 ` Andrii Nakryiko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACdoK4KCbseLYzY2aqVM5KC0oXOwzE-5b3-g07uoeyJN4+r70g@mail.gmail.com \ --to=quentin@isovalent.com \ --cc=andrii.nakryiko@gmail.com \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=netdev@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).