diff mbox series

[v1] libv4l: add missing bpf_common.h header

Message ID 20181102190108.29507-1-ps.report@gmx.net
State Accepted
Headers show
Series [v1] libv4l: add missing bpf_common.h header | expand

Commit Message

Peter Seiderer Nov. 2, 2018, 7:01 p.m. UTC
Fixes [1] (for older toolchains not providing this header):

    CC       keytable.o
  In file included from bpf.h:26:0,
                   from keytable.c:37:
  ../../include/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
   #include <linux/bpf_common.h>
            ^~~~~~~~~~~~~~~~~~~~

[1] http://autobuild.buildroot.org/results/d22c0939eed4bc949f7eaeae7595d01ec45cc2cd

Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
 .../0005-Add-missing-linux-bpf_common.h.patch | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 package/libv4l/0005-Add-missing-linux-bpf_common.h.patch

Comments

Thomas Petazzoni Nov. 3, 2018, 1:28 p.m. UTC | #1
Hello,

On Fri,  2 Nov 2018 20:01:08 +0100, Peter Seiderer wrote:
> Fixes [1] (for older toolchains not providing this header):
> 
>     CC       keytable.o
>   In file included from bpf.h:26:0,
>                    from keytable.c:37:
>   ../../include/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
>    #include <linux/bpf_common.h>
>             ^~~~~~~~~~~~~~~~~~~~
> 
> [1] http://autobuild.buildroot.org/results/d22c0939eed4bc949f7eaeae7595d01ec45cc2cd
> 
> Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> ---
>  .../0005-Add-missing-linux-bpf_common.h.patch | 80 +++++++++++++++++++
>  1 file changed, 80 insertions(+)
>  create mode 100644 package/libv4l/0005-Add-missing-linux-bpf_common.h.patch

Applied to master, thanks. Could you submit this upstream? Thanks!

Thomas
Peter Seiderer Nov. 5, 2018, 8:59 p.m. UTC | #2
Hello Thomas,

On Sat, 3 Nov 2018 14:28:10 +0100, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

> Hello,
> 
> On Fri,  2 Nov 2018 20:01:08 +0100, Peter Seiderer wrote:
> > Fixes [1] (for older toolchains not providing this header):
> > 
> >     CC       keytable.o
> >   In file included from bpf.h:26:0,
> >                    from keytable.c:37:
> >   ../../include/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
> >    #include <linux/bpf_common.h>
> >             ^~~~~~~~~~~~~~~~~~~~
> > 
> > [1] http://autobuild.buildroot.org/results/d22c0939eed4bc949f7eaeae7595d01ec45cc2cd
> > 
> > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > ---
> >  .../0005-Add-missing-linux-bpf_common.h.patch | 80 +++++++++++++++++++
> >  1 file changed, 80 insertions(+)
> >  create mode 100644 package/libv4l/0005-Add-missing-linux-bpf_common.h.patch  
> 
> Applied to master, thanks. Could you submit this upstream? Thanks!

Yes, just done, see [1]...

Regards,
Peter

[1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg136103.html

> 
> Thomas
Fabrice Fontaine Nov. 6, 2018, 8:01 p.m. UTC | #3
Dear Peter,
Le lun. 5 nov. 2018 à 21:59, Peter Seiderer <ps.report@gmx.net> a écrit :
>
> Hello Thomas,
>
> On Sat, 3 Nov 2018 14:28:10 +0100, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
> > Hello,
> >
> > On Fri,  2 Nov 2018 20:01:08 +0100, Peter Seiderer wrote:
> > > Fixes [1] (for older toolchains not providing this header):
> > >
> > >     CC       keytable.o
> > >   In file included from bpf.h:26:0,
> > >                    from keytable.c:37:
> > >   ../../include/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
> > >    #include <linux/bpf_common.h>
> > >             ^~~~~~~~~~~~~~~~~~~~
> > >
> > > [1] http://autobuild.buildroot.org/results/d22c0939eed4bc949f7eaeae7595d01ec45cc2cd
> > >
> > > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > > ---
> > >  .../0005-Add-missing-linux-bpf_common.h.patch | 80 +++++++++++++++++++
> > >  1 file changed, 80 insertions(+)
> > >  create mode 100644 package/libv4l/0005-Add-missing-linux-bpf_common.h.patch
> >
> > Applied to master, thanks. Could you submit this upstream? Thanks!
>
> Yes, just done, see [1]...
Thanks for submitting this patch however build failures remain on some
architectures (ARM cortex a8 / a9 / arm926ej-s) with "old" kernel
headers (3.13) :
- http://autobuild.buildroot.org/results/b48/b48f9b284102d94b847a35ed1ca50a157fbcb1c9/build-end.log
- http://autobuild.buildroot.org/results/339/3391705aca7022111ef743212b7cad57f0cdea9a/build-end.log

Build failures are raised because _NR_bpf is not defined:

bpf.c:48:4: error: #error __NR_bpf not defined. libbpf does not
support your arch.
 #  error __NR_bpf not defined. libbpf does not support your arch.

From my understanding, __NR_bpf should be normally defined by the
kernel (when it is not too old).
For example, __NR_bpf has been defined for m68k and powerpc since 3.18:
- https://github.com/torvalds/linux/commit/f7bbd12a4b7e088f53f20dd31019984459699fb9
- https://github.com/torvalds/linux/commit/fcbb539f279f7d854bd49819b889fea0612909f8
The code in bpf.c only defines fallback for very few few
architectures: i386, x86_64, aarch64, sparc and s390.

So finally, should we add a dependency on
BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18 on a new
BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS option?
>
> Regards,
> Peter
>
> [1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg136103.html
>
> >
> > Thomas
>
Best Regards,

Fabrice
Peter Seiderer Nov. 6, 2018, 10:32 p.m. UTC | #4
Hello Fabrice,

On Tue, 6 Nov 2018 21:01:31 +0100, Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:

> Dear Peter,
> Le lun. 5 nov. 2018 à 21:59, Peter Seiderer <ps.report@gmx.net> a écrit :
> >
> > Hello Thomas,
> >
> > On Sat, 3 Nov 2018 14:28:10 +0100, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> >  
> > > Hello,
> > >
> > > On Fri,  2 Nov 2018 20:01:08 +0100, Peter Seiderer wrote:  
> > > > Fixes [1] (for older toolchains not providing this header):
> > > >
> > > >     CC       keytable.o
> > > >   In file included from bpf.h:26:0,
> > > >                    from keytable.c:37:
> > > >   ../../include/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
> > > >    #include <linux/bpf_common.h>
> > > >             ^~~~~~~~~~~~~~~~~~~~
> > > >
> > > > [1] http://autobuild.buildroot.org/results/d22c0939eed4bc949f7eaeae7595d01ec45cc2cd
> > > >
> > > > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > > > ---
> > > >  .../0005-Add-missing-linux-bpf_common.h.patch | 80 +++++++++++++++++++
> > > >  1 file changed, 80 insertions(+)
> > > >  create mode 100644 package/libv4l/0005-Add-missing-linux-bpf_common.h.patch  
> > >
> > > Applied to master, thanks. Could you submit this upstream? Thanks!  
> >
> > Yes, just done, see [1]...  
> Thanks for submitting this patch however build failures remain on some
> architectures (ARM cortex a8 / a9 / arm926ej-s) with "old" kernel
> headers (3.13) :
> - http://autobuild.buildroot.org/results/b48/b48f9b284102d94b847a35ed1ca50a157fbcb1c9/build-end.log
> - http://autobuild.buildroot.org/results/339/3391705aca7022111ef743212b7cad57f0cdea9a/build-end.log
> 
> Build failures are raised because _NR_bpf is not defined:
> 
> bpf.c:48:4: error: #error __NR_bpf not defined. libbpf does not
> support your arch.
>  #  error __NR_bpf not defined. libbpf does not support your arch.
> 
> From my understanding, __NR_bpf should be normally defined by the
> kernel (when it is not too old).
> For example, __NR_bpf has been defined for m68k and powerpc since 3.18:
> - https://github.com/torvalds/linux/commit/f7bbd12a4b7e088f53f20dd31019984459699fb9
> - https://github.com/torvalds/linux/commit/fcbb539f279f7d854bd49819b889fea0612909f8
> The code in bpf.c only defines fallback for very few few
> architectures: i386, x86_64, aarch64, sparc and s390.
> 
> So finally, should we add a dependency on
> BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18 on a new
> BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS option?

Or add a fallback value for arm (need to investigate the right value for it)...

Regards,
Peter

> >
> > Regards,
> > Peter
> >
> > [1] https://www.mail-archive.com/linux-media@vger.kernel.org/msg136103.html
> >  
> > >
> > > Thomas  
> >  
> Best Regards,
> 
> Fabrice
Peter Korsgaard Nov. 7, 2018, 4:59 p.m. UTC | #5
>>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes:

Hi,

 > Thanks for submitting this patch however build failures remain on some
 > architectures (ARM cortex a8 / a9 / arm926ej-s) with "old" kernel
 > headers (3.13) :
 > - http://autobuild.buildroot.org/results/b48/b48f9b284102d94b847a35ed1ca50a157fbcb1c9/build-end.log
 > - http://autobuild.buildroot.org/results/339/3391705aca7022111ef743212b7cad57f0cdea9a/build-end.log

 > Build failures are raised because _NR_bpf is not defined:

 > bpf.c:48:4: error: #error __NR_bpf not defined. libbpf does not
 > support your arch.
 >  #  error __NR_bpf not defined. libbpf does not support your arch.

 > From my understanding, __NR_bpf should be normally defined by the
 > kernel (when it is not too old).
 > For example, __NR_bpf has been defined for m68k and powerpc since 3.18:
 > - https://github.com/torvalds/linux/commit/f7bbd12a4b7e088f53f20dd31019984459699fb9
 > - https://github.com/torvalds/linux/commit/fcbb539f279f7d854bd49819b889fea0612909f8
 > The code in bpf.c only defines fallback for very few few
 > architectures: i386, x86_64, aarch64, sparc and s390.

But the fallback only fixes setups with older kernel headers than the
runtime kernel, which is IMHO fairly rare in Buildroot - Unless the tool
works correctly when the bpf syscall fails.

 > So finally, should we add a dependency on
 > BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18 on a new
 > BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS option?

The BPF_PROTOCOLS conditional seems to be about using clang to compile
bdf byte code, which is not directly the code that is failing here.

If it is easy to disable bpf support completely, then that is probably
the nicest solution, otherwise I am fine with depending on 3.18, that is
after all almost 4 years old by now.
Fabrice Fontaine Nov. 7, 2018, 7:05 p.m. UTC | #6
Dear Peter,
Le mer. 7 nov. 2018 à 17:59, Peter Korsgaard <peter@korsgaard.com> a écrit :
>
> >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes:
>
> Hi,
>
>  > Thanks for submitting this patch however build failures remain on some
>  > architectures (ARM cortex a8 / a9 / arm926ej-s) with "old" kernel
>  > headers (3.13) :
>  > - http://autobuild.buildroot.org/results/b48/b48f9b284102d94b847a35ed1ca50a157fbcb1c9/build-end.log
>  > - http://autobuild.buildroot.org/results/339/3391705aca7022111ef743212b7cad57f0cdea9a/build-end.log
>
>  > Build failures are raised because _NR_bpf is not defined:
>
>  > bpf.c:48:4: error: #error __NR_bpf not defined. libbpf does not
>  > support your arch.
>  >  #  error __NR_bpf not defined. libbpf does not support your arch.
>
>  > From my understanding, __NR_bpf should be normally defined by the
>  > kernel (when it is not too old).
>  > For example, __NR_bpf has been defined for m68k and powerpc since 3.18:
>  > - https://github.com/torvalds/linux/commit/f7bbd12a4b7e088f53f20dd31019984459699fb9
>  > - https://github.com/torvalds/linux/commit/fcbb539f279f7d854bd49819b889fea0612909f8
>  > The code in bpf.c only defines fallback for very few few
>  > architectures: i386, x86_64, aarch64, sparc and s390.
>
> But the fallback only fixes setups with older kernel headers than the
> runtime kernel, which is IMHO fairly rare in Buildroot - Unless the tool
> works correctly when the bpf syscall fails.
>
>  > So finally, should we add a dependency on
>  > BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18 on a new
>  > BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS option?
>
> The BPF_PROTOCOLS conditional seems to be about using clang to compile
> bdf byte code, which is not directly the code that is failing here.
>
> If it is easy to disable bpf support completely, then that is probably
> the nicest solution, otherwise I am fine with depending on 3.18, that is
> after all almost 4 years old by now.
Thanks for your feedback, I will add a --without-libelf option to configure.ac.
>
> --
> Bye, Peter Korsgaard
Best Regards,

Fabrice
Peter Seiderer Nov. 7, 2018, 10:04 p.m. UTC | #7
Hello Fabrice,

On Wed, 7 Nov 2018 20:05:51 +0100, Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:

> Dear Peter,
> Le mer. 7 nov. 2018 à 17:59, Peter Korsgaard <peter@korsgaard.com> a écrit :
> >  
> > >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes:  
> >
> > Hi,
> >  
> >  > Thanks for submitting this patch however build failures remain on some
> >  > architectures (ARM cortex a8 / a9 / arm926ej-s) with "old" kernel
> >  > headers (3.13) :
> >  > - http://autobuild.buildroot.org/results/b48/b48f9b284102d94b847a35ed1ca50a157fbcb1c9/build-end.log
> >  > - http://autobuild.buildroot.org/results/339/3391705aca7022111ef743212b7cad57f0cdea9a/build-end.log  
> >  
> >  > Build failures are raised because _NR_bpf is not defined:  
> >  
> >  > bpf.c:48:4: error: #error __NR_bpf not defined. libbpf does not
> >  > support your arch.
> >  >  #  error __NR_bpf not defined. libbpf does not support your arch.  
> >  
> >  > From my understanding, __NR_bpf should be normally defined by the
> >  > kernel (when it is not too old).
> >  > For example, __NR_bpf has been defined for m68k and powerpc since 3.18:
> >  > - https://github.com/torvalds/linux/commit/f7bbd12a4b7e088f53f20dd31019984459699fb9
> >  > - https://github.com/torvalds/linux/commit/fcbb539f279f7d854bd49819b889fea0612909f8
> >  > The code in bpf.c only defines fallback for very few few
> >  > architectures: i386, x86_64, aarch64, sparc and s390.  
> >
> > But the fallback only fixes setups with older kernel headers than the
> > runtime kernel, which is IMHO fairly rare in Buildroot - Unless the tool
> > works correctly when the bpf syscall fails.
> >  
> >  > So finally, should we add a dependency on
> >  > BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18 on a new
> >  > BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS option?  
> >
> > The BPF_PROTOCOLS conditional seems to be about using clang to compile
> > bdf byte code, which is not directly the code that is failing here.
> >
> > If it is easy to disable bpf support completely, then that is probably
> > the nicest solution, otherwise I am fine with depending on 3.18, that is
> > after all almost 4 years old by now.  
> Thanks for your feedback, I will add a --without-libelf option to configure.ac.

No libelf is not enough for disabling bpf, see the autobuild failure [1]:

[...]
checking for LIBELF... no
configure: WARNING: libelf library not available
[...]
In file included from bpf.h:26:0,
                 from keytable.c:37:
../../include/linux/bpf.h:12:30: fatal error: linux/bpf_common.h: No such file or directory
 #include <linux/bpf_common.h>
                              ^

Maybe take a look at the upstream efforts:

[PATCH v2 v4l-utils] configure: build without BPF support in ir-keytable
https://patchwork.linuxtv.org/patch/52841/

Regards,
Peter

[1] http://autobuild.buildroot.org/results/d22c0939eed4bc949f7eaeae7595d01ec45cc2cd/build-end.log

> >
> > --
> > Bye, Peter Korsgaard  
> Best Regards,
> 
> Fabrice
diff mbox series

Patch

diff --git a/package/libv4l/0005-Add-missing-linux-bpf_common.h.patch b/package/libv4l/0005-Add-missing-linux-bpf_common.h.patch
new file mode 100644
index 0000000000..d43ea70027
--- /dev/null
+++ b/package/libv4l/0005-Add-missing-linux-bpf_common.h.patch
@@ -0,0 +1,80 @@ 
+From 311e344039d58cfde09dd34f14804db8ac0513c9 Mon Sep 17 00:00:00 2001
+From: Peter Seiderer <ps.report@gmx.net>
+Date: Fri, 2 Nov 2018 18:58:53 +0100
+Subject: [PATCH] Add missing linux/bpf_common.h
+
+Copy from [1], needed by bpf.h.
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf_common.h?h=v4.19
+Signed-off-by: Peter Seiderer <ps.report@gmx.net>
+---
+ include/linux/bpf_common.h | 57 ++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 57 insertions(+)
+ create mode 100644 include/linux/bpf_common.h
+
+diff --git a/include/linux/bpf_common.h b/include/linux/bpf_common.h
+new file mode 100644
+index 00000000..ee97668b
+--- /dev/null
++++ b/include/linux/bpf_common.h
+@@ -0,0 +1,57 @@
++/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
++#ifndef _UAPI__LINUX_BPF_COMMON_H__
++#define _UAPI__LINUX_BPF_COMMON_H__
++
++/* Instruction classes */
++#define BPF_CLASS(code) ((code) & 0x07)
++#define		BPF_LD		0x00
++#define		BPF_LDX		0x01
++#define		BPF_ST		0x02
++#define		BPF_STX		0x03
++#define		BPF_ALU		0x04
++#define		BPF_JMP		0x05
++#define		BPF_RET		0x06
++#define		BPF_MISC        0x07
++
++/* ld/ldx fields */
++#define BPF_SIZE(code)  ((code) & 0x18)
++#define		BPF_W		0x00 /* 32-bit */
++#define		BPF_H		0x08 /* 16-bit */
++#define		BPF_B		0x10 /*  8-bit */
++/* eBPF		BPF_DW		0x18    64-bit */
++#define BPF_MODE(code)  ((code) & 0xe0)
++#define		BPF_IMM		0x00
++#define		BPF_ABS		0x20
++#define		BPF_IND		0x40
++#define		BPF_MEM		0x60
++#define		BPF_LEN		0x80
++#define		BPF_MSH		0xa0
++
++/* alu/jmp fields */
++#define BPF_OP(code)    ((code) & 0xf0)
++#define		BPF_ADD		0x00
++#define		BPF_SUB		0x10
++#define		BPF_MUL		0x20
++#define		BPF_DIV		0x30
++#define		BPF_OR		0x40
++#define		BPF_AND		0x50
++#define		BPF_LSH		0x60
++#define		BPF_RSH		0x70
++#define		BPF_NEG		0x80
++#define		BPF_MOD		0x90
++#define		BPF_XOR		0xa0
++
++#define		BPF_JA		0x00
++#define		BPF_JEQ		0x10
++#define		BPF_JGT		0x20
++#define		BPF_JGE		0x30
++#define		BPF_JSET        0x40
++#define BPF_SRC(code)   ((code) & 0x08)
++#define		BPF_K		0x00
++#define		BPF_X		0x08
++
++#ifndef BPF_MAXINSNS
++#define BPF_MAXINSNS 4096
++#endif
++
++#endif /* _UAPI__LINUX_BPF_COMMON_H__ */
+-- 
+2.19.1
+