Re: Rust kernel policy

Theodore Ts'o
2025-02-19T17:06:37Z

On Wed, Feb 19, 2025 at 05:44:16PM +0100, Miguel Ojeda wrote:
> Hmm... I am not sure exactly what you mean here. Are you referring to
> Wedson's FS slides from LSF/MM/BPF? i.e are you referring to Rust
> signatures?
>
> If yes, those signatures are manually written, they are not the
> generated bindings. We typically refer to those as "abstractions", to
> differentiate from the generated stuff.

The problem with the bindings in Wedson's FS slides is that it's
really unreasonable to expect C programmers to understand them. In my
opinion, it was not necessarily a wise decision to use bindings as
hyper-complex as a way to convince C developers that Rust was a net
good thing.

I do understand (now) what Wedson was trying to do, was to show off
how expressive and powerful Rust can be, even in the face of a fairly
complex interface. It turns out there were some good reasons for why
the VFS handles inode creation, but in general, I'd encourage us to
consider whether there are ways to change the abstractions on the C
side so that:

(a) it makes it easier to maintain the Rust bindings, perhaps even
using automatically generation tools,
(b) it allows Rust newbies having at least some *hope* of updating
the manually maintained bindings,
(c) without causing too much performance regressions, especially
on hot paths, and
(d) hopefully making things easier for new C programmers from
understanding the interface in question.

So it might not be that increasing C safety isn't the primary goal, in
general, one of the ways that we evaluate a particular patchset is
whether addresses multiple problems at the same time. If it does,
that's a signal that perhaps it's the right direction for us to go.

Cheers,

- Ted