Re: [PATCH v3 bpf-next 5/7] libbpf: move bpf_{helpers,endian,tracing}.h into libbpf
From: David Ahern <hidden>
Date: 2019-10-04 15:44:48
Also in:
bpf
On 10/4/19 9:27 AM, Andrii Nakryiko wrote:
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.
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.