Re: [PATCH v3 bpf-next 5/7] libbpf: move bpf_{helpers,endian,tracing}.h into libbpf
From: Andrii Nakryiko <hidden>
Date: 2019-10-04 16:00:57
Also in:
bpf
On Fri, Oct 4, 2019 at 8:44 AM David Ahern [off-list ref] wrote:
On 10/4/19 9:27 AM, Andrii Nakryiko wrote:quoted
On Fri, Oct 4, 2019 at 7:47 AM David Ahern [off-list ref] wrote:quoted
On 10/3/19 3:28 PM, Andrii Nakryiko wrote:quoted
Move bpf_helpers.h, bpf_tracing.h, and bpf_endian.h into libbpf. Ensure they are installed along the other libbpf headers. Also, adjust selftests and samples include path to include libbpf now.There are side effects to bringing bpf_helpers.h into libbpf if this gets propagated to the github sync. bpf_helpers.h references BPF_FUNC_* which are defined in the uapi/linux/bpf.h header. That is a kernel version dependent api file which means attempts to use newer libbpf with older kernel headers is going to throw errors when compiling bpf programs -- bpf_helpers.h will contain undefined BPF_FUNC references.That's true, but I'm wondering if maintaining a copy of that enum in bpf_helpers.h itself is a good answer here? bpf_helpers.h will be most probably used with BPF CO-RE and auto-generated vmlinux.h with all the enums and types. In that case, you'll probably want to use vmlinux.h for one of the latest kernels anyways.I'm not following you; my interpretation of your comment seems like you are making huge assumptions. I build bpf programs for specific kernel versions using the devel packages for the specific kernel of interest.
Sure, and you can keep doing that, just don't include bpf_helpers.h? What I was saying, though, especially having in mind tracing BPF programs that need to inspect kernel structures, is that it's quite impractical to have to build many different versions of BPF programs for each supported kernel version and distribute them in binary form. So people usually use BCC and do compilation on-the-fly using BCC's embedded Clang. BPF CO-RE is providing an alternative, which will allow to pre-compile your program once for many different kernels you might be running your program on. There is tooling that eliminates the need for system headers. Instead we pre-generate a single vmlinux.h header with all the types/enums/etc, that are then used w/ BPF CO-RE to build portable BPF programs capable of working on multiple kernel versions. So what I was pointing out there was that this vmlinux.h would be ideally generated from latest kernel and not having latest BPF_FUNC_xxx shouldn't be a problem. But see below about situation being worse.
quoted
Nevertheless, it is a problem and thanks for bringing it up! I'd say for now we should still go ahead with this move and try to solve with issue once bpf_helpers.h is in libbpf. If bpf_helpers.h doesn't work for someone, it's no worse than it is today when users don't have bpf_helpers.h at all.If this syncs to the github libbpf, it will be worse than today in the sense of compile failures if someone's header file ordering picks libbpf's bpf_helpers.h over whatever they are using today.
Today bpf_helpers.h don't exist for users or am I missing something? bpf_helpers.h right now are purely for selftests. But they are really useful outside that context, so I'm making it available for everyone by distributing with libbpf sources. If bpf_helpers.h doesn't work for some specific use case, just don't use it (yet?). I'm still failing to see how it's worse than situation today.