* Clarifications on linux/types.h used with libbpf
@ 2022-02-15 12:57 Marco Vedovati
2022-02-15 13:18 ` Marco Vedovati
2022-02-17 22:08 ` Andrii Nakryiko
0 siblings, 2 replies; 5+ messages in thread
From: Marco Vedovati @ 2022-02-15 12:57 UTC (permalink / raw)
To: bpf, toke
Cc: netdev, kernel-team, Martin Kelly, ast, daniel, davem, Andrii Nakryiko
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Clarifications on linux/types.h used with libbpf
2022-02-15 12:57 Clarifications on linux/types.h used with libbpf Marco Vedovati
@ 2022-02-15 13:18 ` Marco Vedovati
2022-02-17 22:08 ` Andrii Nakryiko
1 sibling, 0 replies; 5+ messages in thread
From: Marco Vedovati @ 2022-02-15 13:18 UTC (permalink / raw)
To: bpf, toke
Cc: netdev, kernel-team, Martin Kelly, ast, daniel, davem, Andrii Nakryiko
(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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Clarifications on linux/types.h used with libbpf
2022-02-15 12:57 Clarifications on linux/types.h used with libbpf Marco Vedovati
2022-02-15 13:18 ` Marco Vedovati
@ 2022-02-17 22:08 ` Andrii Nakryiko
2022-02-23 20:18 ` Marco Vedovati
1 sibling, 1 reply; 5+ messages in thread
From: Andrii Nakryiko @ 2022-02-17 22:08 UTC (permalink / raw)
To: Marco Vedovati
Cc: bpf, toke, netdev, kernel-team, Martin Kelly, ast, daniel, davem,
Andrii Nakryiko
On Tue, Feb 15, 2022 at 4:58 AM Marco Vedovati
<marco.vedovati@crowdstrike.com> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Clarifications on linux/types.h used with libbpf
2022-02-17 22:08 ` Andrii Nakryiko
@ 2022-02-23 20:18 ` Marco Vedovati
2022-02-23 21:58 ` Andrii Nakryiko
0 siblings, 1 reply; 5+ messages in thread
From: Marco Vedovati @ 2022-02-23 20:18 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, toke, netdev, kernel-team, Martin Kelly, ast, daniel, davem,
Andrii Nakryiko
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
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
> <marco.vedovati@crowdstrike.com> 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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Clarifications on linux/types.h used with libbpf
2022-02-23 20:18 ` Marco Vedovati
@ 2022-02-23 21:58 ` Andrii Nakryiko
0 siblings, 0 replies; 5+ messages in thread
From: Andrii Nakryiko @ 2022-02-23 21:58 UTC (permalink / raw)
To: Marco Vedovati
Cc: bpf, toke, netdev, kernel-team, Martin Kelly, ast, daniel, davem,
Andrii Nakryiko
On Wed, Feb 23, 2022 at 12:18 PM Marco Vedovati
<marco.vedovati@crowdstrike.com> wrote:
>
> From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
> 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
> > <marco.vedovati@crowdstrike.com> 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.
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.
>
> >
> > Thanks,
> > Marco
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-02-23 21:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-15 12:57 Clarifications on linux/types.h used with libbpf Marco Vedovati
2022-02-15 13:18 ` Marco Vedovati
2022-02-17 22:08 ` Andrii Nakryiko
2022-02-23 20:18 ` Marco Vedovati
2022-02-23 21:58 ` Andrii Nakryiko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).