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

[Steven Rostedt <rostedt@goodmis.org>]

[ Switched over to ksummit@lists.linux.dev ]

On Fri, 17 Jun 2022 13:25:04 +0200
Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:

> > I think you need to clarify here that you mean changing some settings
> > on the device through e.g. a HID feature report which would require
> > a sysfs-attribute or kernel-module-parameters without ePBF and you want
> > to avoid adding more and more sysfs-attributes / kernel-module-parameters?  
> 
> Yep yep :)

And that is perfectly acceptable, and something I would support.

> 
> >
> > At least I think this is what you are trying to say, and I think that
> > without some clarification this is not what most kernel-devs will
> > understand here.  

This statement is the issue. There's not a clear line of what
constitutes what eBPF is being used for, and worse, what is guaranteed
to work across kernel versions.

My fear is that we will start having an expectation that pretty much
any eBPF program will continue to work, and there's going to be a lot
of disgruntled users when it doesn't.

Having configuration uses is one thing, enabling full device
functionality is another. And anything that touches core interfaces
need to be scrutinized.

If we look at where BPF came from (iptables et.al.) and having it do
nothing more that that but for other parts of the system, it may be a
good start. But even that could introduce dependencies of internal
kernel implementations that could break over time. Basically, we can
try to not break BPF programs but we really need the decree that it's
not user API, and does not follow the "don't break user space" agenda,
as anything that uses eBPF, is *not* user space. It's just another kind
of kernel module.

And if an eBPF program does break, if the source of that program is not
available, then the answer to fixing it should be "tough luck". This
should not be a way for proprietary code to have their kernel API.

-- Steve