Re: Rust kernel policy

Jiri Kosina
2025-02-18T17:36:58Z

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