Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com> To: Quentin Monnet <quentin@isovalent.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 14:54:03 -0700 [thread overview] Message-ID: <CAEf4BzbaHyGxEYx_+DjaeVhUt5qZS=tMKmAqG9MPZziQHUHPiw@mail.gmail.com> (raw) In-Reply-To: <CACdoK4KCbseLYzY2aqVM5KC0oXOwzE-5b3-g07uoeyJN4+r70g@mail.gmail.com> On Fri, Jul 30, 2021 at 1:23 PM Quentin Monnet <quentin@isovalent.com> wrote: > > 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. Oh, in that sense. Yeah, sure, I didn't think that would qualify as tricky. But yeah, -I$(OUTPUT) or something along those lines is fine. > > > > > > > > > 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. Cool, `make install` is the best way as it prevents accidental usage of libbpf's internal header. So it's a good change to make.
prev parent reply other threads:[~2021-07-30 21:54 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 2021-07-30 21:54 ` Andrii Nakryiko [this message]
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='CAEf4BzbaHyGxEYx_+DjaeVhUt5qZS=tMKmAqG9MPZziQHUHPiw@mail.gmail.com' \ --to=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 \ --cc=quentin@isovalent.com \ /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).