On 10/4/19 9:27 AM, Andrii Nakryiko wrote: > 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. 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.
