On Tue, Feb 15, 2022 at 4:58 AM Marco Vedovati <marco.vedovati@xxxxxxxxxxxxxxx> wrote: > > Hi, > > I have few questions about the linux/types.h file used to build bpf > applications. This file gets included by both userspace applications using > libbpf and by bpf programs. E.g., in a userspace application: > foo.c > foo.skel.h > bpf/libbpf.h > linux/bpf.h > linux/types.h > > Or in a bpf program: > foo.bpf.c > linux/bpf.h > linux/types.h > > libbpf provides its own copy of this file in include/linux/types.h. > As I could understand from the Git history, it was initially copied from > linux include/linux/types.h, but it is now maintained separately. > > Both linux bpftool and bpf selftests however are built using another > types.h from tools/include/uapi/linux/types.h. > Is there a reason why bpftool and selftests aren't built using the same > types.h distributed by libbpf? > > I also see that the license of the three files differs: > - (libbpf) include/linux/types.h is "LGPL-2.1 OR BSD-2-Clause" > - (linux) include/linux/types.h is "GPL-2.0" > - (linux) tools/include/uapi/linux/types.h is "GPL-2.0" > Is there a reason why tools/include/uapi/linux/types.h isn't licensed as > "GPL-2.0 WITH Linux-syscall-note"? > > Finally, would it make sense to also have libbpf use > tools/include/uapi/linux/types.h instead of its own copy? > The advantages would be: > - consistency with linux use > - the only architecture specific header included is "asm/bitsperlong.h", > instead of all the ones currently included. include/uapi/linux/types.h (UAPI header) is different from include/linux/types.h (kernel-internal header). Libbpf has to reimplement minimum amount of declarations from kernel-internal include/linux/types.h to build outside of the kernel. But short answer is they are different headers, so I suspect that no, libbpf can't use just UAPI version. > > Thanks, > Marco