Re: Rust kernel policy

[Jiri Kosina <jikos@kernel.org>]

On Tue, 18 Feb 2025, Christoph Hellwig wrote:

> So we'll have these bindings creep everywhere like a cancer and are
> very quickly moving from a software project that allows for and strives
> for global changes that improve the overall project to increasing
> compartmentalization [2].
[ ... ]

> [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).

This is not growing anywhere beyond pretty much a few hooks to make 
writing HID-eBPF driver code more convenient compared to creating a 
full-fledged kernel one.

It's mostly useful for quick-turnaround debugging with users who are not 
generally capable of compiling kernel modules / applying patches to test 
fixes, although the usage is admittedly slightly expanding beyond that.

To me that's something completely different than making changes (or 
bindings, "ABI stability contracts", or however we want to call it) that 
are pretty much impossible to revert, because everything quickly becomes 
depending on the new core code.

-- 
Jiri Kosina
SUSE Labs