diff mbox series

[v4l-utils] Add missing linux/bpf_common.h

Message ID 20181105203047.15258-1-ps.report@gmx.net (mailing list archive)
State New, archived
Headers show
Series [v4l-utils] Add missing linux/bpf_common.h | expand

Commit Message

Peter Seiderer Nov. 5, 2018, 8:30 p.m. UTC 
Copy from [1], needed by bpf.h.

[1] 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

Comments

Sean Young Nov. 6, 2018, 10:38 a.m. UTC | #1 
On Mon, Nov 05, 2018 at 09:30:47PM +0100, Peter Seiderer wrote:
> Copy from [1], needed by bpf.h.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf_common.h?h=v4.19

So bpf.h does include this file, but we don't use anything from it in
v4l-utils.

This include file is for the original BPF, which has been around for a
long time. So why is this include file missing, i.e. what problem are you
trying to solve?

Lastely, the file should be included in the sync-with-kernel target so
it does not get out of sync -- should it really be necessary to add the
file.


Sean

> 
> 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
Peter Seiderer Nov. 6, 2018, 9:43 p.m. UTC | #2 
Hello Sean,

On Tue, 6 Nov 2018 10:38:56 +0000, Sean Young <sean@mess.org> wrote:

> On Mon, Nov 05, 2018 at 09:30:47PM +0100, Peter Seiderer wrote:
> > Copy from [1], needed by bpf.h.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf_common.h?h=v4.19
>
> So bpf.h does include this file, but we don't use anything from it in
> v4l-utils.
>

Maybe alternative fix is to remove the include (or not if your want
the headers to be in sync with the kernel ones, but then they should
be complete enough to be used for compile)?

> This include file is for the original BPF, which has been around for a
> long time. So why is this include file missing, i.e. what problem are you
> trying to solve?

A buildroot autobuild failure (see [1] for details) with older toolchains
not providing this header...

>
> Lastely, the file should be included in the sync-with-kernel target so
> it does not get out of sync -- should it really be necessary to add the
> file.

O.k, can do it on next patch iteration...

Regards,
Peter

[1] http://lists.busybox.net/pipermail/buildroot/2018-November/234840.html

>
>
> Sean
>
> >
> > 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
Sean Young Nov. 7, 2018, 12:05 p.m. UTC | #3 
Hi Peter,

On Tue, Nov 06, 2018 at 10:43:58PM +0100, Peter Seiderer wrote:
> On Tue, 6 Nov 2018 10:38:56 +0000, Sean Young <sean@mess.org> wrote:
> 
> > On Mon, Nov 05, 2018 at 09:30:47PM +0100, Peter Seiderer wrote:
> > > Copy from [1], needed by bpf.h.
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf_common.h?h=v4.19
> >
> > So bpf.h does include this file, but we don't use anything from it in
> > v4l-utils.
> >
> 
> Maybe alternative fix is to remove the include (or not if your want
> the headers to be in sync with the kernel ones, but then they should
> be complete enough to be used for compile)?
> 
> > This include file is for the original BPF, which has been around for a
> > long time. So why is this include file missing, i.e. what problem are you
> > trying to solve?
> 
> A buildroot autobuild failure (see [1] for details) with older toolchains
> not providing this header...
> 
> >
> > Lastely, the file should be included in the sync-with-kernel target so
> > it does not get out of sync -- should it really be necessary to add the
> > file.
> 
> O.k, can do it on next patch iteration...
> 
> Regards,
> Peter
> 
> [1] http://lists.busybox.net/pipermail/buildroot/2018-November/234840.html

So here libelf was not detected, hence ir-keytable should have been built
without BPF support, but it is still including bpf.h despite it not
being used.

I've just sent a patch for better support for building without BPF,
see here:
	https://patchwork.linuxtv.org/patch/52841/


Would you mind seeing if that works for you?


Thanks,

Sean
Peter Seiderer Nov. 8, 2018, 9:13 p.m. UTC | #4 
Hello Sean,

On Wed, 7 Nov 2018 12:05:45 +0000, Sean Young <sean@mess.org> wrote:

> Hi Peter,
> 
> On Tue, Nov 06, 2018 at 10:43:58PM +0100, Peter Seiderer wrote:
> > On Tue, 6 Nov 2018 10:38:56 +0000, Sean Young <sean@mess.org> wrote:
> >   
> > > On Mon, Nov 05, 2018 at 09:30:47PM +0100, Peter Seiderer wrote:  
> > > > Copy from [1], needed by bpf.h.
> > > >
> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf_common.h?h=v4.19  
> > >
> > > So bpf.h does include this file, but we don't use anything from it in
> > > v4l-utils.
> > >  
> > 
> > Maybe alternative fix is to remove the include (or not if your want
> > the headers to be in sync with the kernel ones, but then they should
> > be complete enough to be used for compile)?
> >   
> > > This include file is for the original BPF, which has been around for a
> > > long time. So why is this include file missing, i.e. what problem are you
> > > trying to solve?  
> > 
> > A buildroot autobuild failure (see [1] for details) with older toolchains
> > not providing this header...
> >   
> > >
> > > Lastely, the file should be included in the sync-with-kernel target so
> > > it does not get out of sync -- should it really be necessary to add the
> > > file.  
> > 
> > O.k, can do it on next patch iteration...
> > 
> > Regards,
> > Peter
> > 
> > [1] http://lists.busybox.net/pipermail/buildroot/2018-November/234840.html  
> 
> So here libelf was not detected, hence ir-keytable should have been built
> without BPF support, but it is still including bpf.h despite it not
> being used.
> 
> I've just sent a patch for better support for building without BPF,
> see here:
> 	https://patchwork.linuxtv.org/patch/52841/
> 
> 
> Would you mind seeing if that works for you?

Thanks, works for the buildroot use case (disabling
bpf support unconditionally)...

The reason to provide copies of the linux kernel headers in  v4l-utils
is to be independent of old(-er) headers provided by toolchains?

If so a copy of bpf_common.h is still needed (and the fallback, for
out of linux kernel usage, define for __NR_bpf in bpf.h enhanced for
all supported archs)?

Regards,
Peter

> 
> 
> Thanks,
> 
> Sean
Sean Young Nov. 9, 2018, 12:10 p.m. UTC | #5 
Hi Peter,

On Thu, Nov 08, 2018 at 10:13:38PM +0100, Peter Seiderer wrote:
> Thanks, works for the buildroot use case (disabling
> bpf support unconditionally)...
> 
> The reason to provide copies of the linux kernel headers in  v4l-utils
> is to be independent of old(-er) headers provided by toolchains?
> 
> If so a copy of bpf_common.h is still needed (and the fallback, for
> out of linux kernel usage, define for __NR_bpf in bpf.h enhanced for
> all supported archs)?

I have seen this problem on debian 7. Why do we care about compiling
on something that ancient?


Sean
Peter Seiderer Nov. 9, 2018, 9:22 p.m. UTC | #6 
Hello Sean,

On Fri, 9 Nov 2018 12:10:38 +0000, Sean Young <sean@mess.org> wrote:

> Hi Peter,
> 
> On Thu, Nov 08, 2018 at 10:13:38PM +0100, Peter Seiderer wrote:
> > Thanks, works for the buildroot use case (disabling
> > bpf support unconditionally)...
> > 
> > The reason to provide copies of the linux kernel headers in  v4l-utils
> > is to be independent of old(-er) headers provided by toolchains?
> > 
> > If so a copy of bpf_common.h is still needed (and the fallback, for
> > out of linux kernel usage, define for __NR_bpf in bpf.h enhanced for
> > all supported archs)?  
> 
> I have seen this problem on debian 7. Why do we care about compiling
> on something that ancient?

It is not about compiling on what system, it is about which toolchain 
is used (for cross-compile), and the initial failure comes from
the buildroot [1] embedded system autobuild tests...

Personally I do not care about these toolchains (but the buildroot
people think it is worth to do automatic build tests with them) and
can live with the disabling of the bpf support....

Regards,
Peter
 
[1] https://buildroot.org/

> 
> 
> Sean
diff mbox series

Patch

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__ */