Re: Rust kernel policy

Miguel Ojeda
2025-02-20T23:41:10Z

On Wed, Feb 19, 2025 at 6:06 PM Theodore Ts'o <tytso@mit.edu> wrote:
>
> 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.

Thanks for saying that.

> 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:

Definitely -- improving the C side (not just for Rust callers, but
also for C ones) would be great, whether that is with extra
annotations/extensions or redesigns.

In the beginning (pre-merge), we tried hard not to require changes on
the C side, because we wanted to show that it is possible to use Rust
(i.e. create safe abstractions for C APIs) even with minimal or no
changes to C headers. We thought it was a useful property.

But then we got C maintainers that welcomed improvements that would
benefit both sides, which was nice to see, and opens up some doors --
as a simple example, Greg added made some APIs `const`-correct so that
we got the right pointer type on the Rust bindings.

So, yeah, anything in that direction (that either improves the C side
and/or simplifies the Rust bindings/abstractions) would be great.

Cheers,
Miguel