Hi Sean, I finally found the time to test your patch series and noticed 2 issues - comments are inline On Sun, May 27, 2018 at 12:24:09PM +0100, Sean Young wrote: > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > index eb2c3b6eca7f..d5b35a6ba899 100644 > --- a/drivers/media/rc/Kconfig > +++ b/drivers/media/rc/Kconfig > @@ -25,6 +25,19 @@ config LIRC > passes raw IR to and from userspace, which is needed for > IR transmitting (aka "blasting") and for the lirc daemon. > > +config BPF_LIRC_MODE2 > + bool "Support for eBPF programs attached to lirc devices" > + depends on BPF_SYSCALL > + depends on RC_CORE=y Requiring rc-core to be built into the kernel could become problematic in the future for people using media_build. Currently the whole media tree (including rc-core) can be built as modules so DVB and IR drivers can be replaced by newer versions. But with rc-core in the kernel things could easily break if internal data structures are changed. Maybe we should add a small layer with a stable API/ABI between bpf-lirc and rc-core to decouple them? Or would it be possible to build rc-core with bpf support as a module? > + depends on LIRC > + help > + Allow attaching eBPF programs to a lirc device using the bpf(2) > + syscall command BPF_PROG_ATTACH. This is supported for raw IR > + receivers. > + > + These eBPF programs can be used to decode IR into scancodes, for > + IR protocols not supported by the kernel decoders. > + > menuconfig RC_DECODERS > bool "Remote controller decoders" > depends on RC_CORE > [...] > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c > index 388d4feda348..3c104113d040 100644 > --- a/kernel/bpf/syscall.c > +++ b/kernel/bpf/syscall.c > @@ -11,6 +11,7 @@ > */ > #include <linux/bpf.h> > #include <linux/bpf_trace.h> > +#include <linux/bpf_lirc.h> > #include <linux/btf.h> > #include <linux/syscalls.h> > #include <linux/slab.h> > @@ -1578,6 +1579,8 @@ static int bpf_prog_attach(const union bpf_attr *attr) > case BPF_SK_SKB_STREAM_PARSER: > case BPF_SK_SKB_STREAM_VERDICT: > return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, true); > + case BPF_LIRC_MODE2: > + return lirc_prog_attach(attr); > default: > return -EINVAL; > } > @@ -1648,6 +1651,8 @@ static int bpf_prog_detach(const union bpf_attr *attr) > case BPF_SK_SKB_STREAM_PARSER: > case BPF_SK_SKB_STREAM_VERDICT: > return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, false); > + case BPF_LIRC_MODE2: > + return lirc_prog_detach(attr); > default: > return -EINVAL; > } > @@ -1695,6 +1700,8 @@ static int bpf_prog_query(const union bpf_attr *attr, > case BPF_CGROUP_SOCK_OPS: > case BPF_CGROUP_DEVICE: > break; > + case BPF_LIRC_MODE2: > + return lirc_prog_query(attr, uattr); When testing this patch series I was wondering why I always got -EINVAL when trying to query the registered programs. Closer inspection revealed that bpf_prog_attach/detach/query and calls to them in the bpf syscall are in "#ifdef CONFIG_CGROUP_BPF" blocks - and as I built the kernel without CONFIG_CGROUP_BPF BPF_PROG_ATTACH/DETACH/QUERY weren't handled in the syscall switch and I got -EINVAL from the bpf syscall function. I haven't checked in detail yet, but it looks to me like bpf_prog_attach/detach/query could always be built (or when either cgroup bpf or lirc bpf are enabled) and the #ifdefs moved inside the switch(). So lirc bpf could be used without cgroup bpf. Or am I missing something? so long, Hias > default: > return -EINVAL; > } > -- > 2.17.0 >
