From: Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx>
Sent: Thursday, February 17, 2022 11:08 PM
To: Marco Vedovati
Cc: bpf@xxxxxxxxxxxxxxx; toke@xxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; kernel-team@xxxxxx; Martin Kelly; ast@xxxxxxxxxx; daniel@xxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; Andrii Nakryiko
Subject: [External] Re: Clarifications on linux/types.h used with libbpf
> 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
> [cut]
>
>
> 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.
Thank you for clarifying some of my confusions.
So if I understood correctly, the only use of libbpf:include/linux/types.h
is to allow building the library out of the kernel tree.
An ambiguity I have found is about what version of linux/types.h to use
use when building bpf source code (that includes <linux/bpf.h>).
I saw 2 options:
- do like libbpf-bootstrap C examples, that uses whatever linux/types.h
version available on the building host. This is however adding more
dependencies that are satisfied with extra "-idirafter" compiler options.
- do like bpftool's makefile, that builds bpf source code by including
tools/include/uapi/. This does not require the "-idirafter" trick.
Anyway, checking the history of "tools/include/uapi/linux/types.h", I
believe that this file is mistakenly licensed as "GPL-2.0" instead of
"GPL-2.0 WITH Linux-syscall-note". I may come up with a patch to fix it.
>
> Thanks,
> Marco
