Re: Rust kernel policy

[Alexei Starovoitov]

On Wed, Feb 19, 2025 at 10:33 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>
> On Tue, Feb 18, 2025 at 06:36:55PM +0100, Jiri Kosina wrote:
> > > [2] The idea of drivers in eBPF as done by HID also really doesn't help
> > > with that as much as I like eBPF for some use cases
> >
> > I don't necessarily agree on this specific aspect, but what (at least to
> > me personally) is the crucial point here -- if we at some point decide
> > that HID-eBPF is somehow potentially unhealthy for the project /
> > ecosystem, we can just drop it and convert the existing eBPF snippets to a
> > proper simple HID bus drivers trivially (I'd even dare to say that to some
> > extent perhaps programatically).
>
> Well, Linus declared any bpf kfunc / helper program type change that
> breaks userspace as a no-go.  And such a change very much does.

Have to chime in into this rust thread to correct the facts.

See the doc:
https://github.com/torvalds/linux/blob/master/Documentation/bpf/kfuncs.rst#3-kfunc-lifecycle-expectations
TLDR:
"A kfunc will never have any hard stability guarantees. BPF APIs
cannot and will not ever hard-block a change in the kernel..."

git log proves the history of changing/removing kfuncs.

hid-bpf iself is another example of that policy.
It was redesigned from one way of hooking into hid core to
a completely different approach.
It may happen again, if necessary.