[Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF

[Jiri Kosina <jikos@kernel.org>]

On Wed, 15 Jun 2022, Benjamin Tissoires wrote:

> One point that was also raised in the various HID-BPF patch series is 
> that for "hardware enablement" like support, the eBPF programs would be 
> in-tree, and automatically loaded by the kernel itself.
> 
> Alexei has some ideas on how to implement that, I had others, but the 
> hallway track discussions showed that everybody has a different idea on 
> the automatic mechanism, but it is a requirement and worth discussing :)
> 
> Which means that in that case, eBPF would be a more convenient way for 
> users to fix their device, without having to rely on a full or partial 
> kernel recompilation.

That definitely does solve one of the issues. It's basically following the 
model of perf, where the ABI must not be kept intact, because the user(s) 
of it are in-tree and released in lockstep with the ABI changes.

> While working on eBPF, I came to realize how hidraw is bad in terms of 
> development model for userspace "drivers". 

As the original author of hidraw, I have to agree :) I didn't expect such 
an explosion of userspace drivers being dependent on it, it was primarily 
meant for debugging and tweaking.

libusb is a similar example, I believe.

-- 
Jiri Kosina
SUSE Labs