Clarifications on linux/types.h used with libbpf

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.

Thanks,
Marco

(resending as my first email was sent without ml subscription)
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.

Thanks,
Marco

On Tue, Feb 15, 2022 at 4:58 AM Marco Vedovati
[off-list ref] 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

From: Andrii Nakryiko <redacted>
Sent: Thursday, February 17, 2022 11:08 PM
To: Marco Vedovati
Cc: bpf@vger.kernel.org; toke@redhat.com; netdev@vger.kernel.org; kernel-team@fb.com; Martin Kelly; ast@kernel.org; daniel@iogearbox.net; davem@davemloft.net; Andrii Nakryiko
Subject: [External] Re: Clarifications on linux/types.h used with libbpf
    

On Tue, Feb 15, 2022 at 4:58 AM Marco Vedovati
[off-list ref] wrote:

quoted

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

On Wed, Feb 23, 2022 at 12:18 PM Marco Vedovati
[off-list ref] wrote:

From: Andrii Nakryiko <redacted>
Sent: Thursday, February 17, 2022 11:08 PM
To: Marco Vedovati
Cc: bpf@vger.kernel.org; toke@redhat.com; netdev@vger.kernel.org; kernel-team@fb.com; Martin Kelly; ast@kernel.org; daniel@iogearbox.net; davem@davemloft.net; Andrii Nakryiko
Subject: [External] Re: Clarifications on linux/types.h used with libbpf

quoted

On Tue, Feb 15, 2022 at 4:58 AM Marco Vedovati
[off-list ref] wrote:

quoted

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.

Applications shouldn't be building against Linux-internal
include/linux/types.h. It should always be resolved to
include/uapi/linux/types.h.

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.

quoted

Thanks,
Marco