On Fri, Oct 4, 2019 at 7:47 AM David Ahern <dsahern@xxxxxxxxx> wrote: > > On 10/3/19 3:28 PM, Andrii Nakryiko wrote: > > 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. 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.
