On Thu, Jun 19, 2025 at 9:35 PM Benno Lossin <lossin@xxxxxxxxxx> wrote:
>
> There are some subsystems that go for a library approach: extract some
> self-contained piece of functionality and move it to Rust code and then
> call that from C. I personally don't really like this approach, as it
> makes it hard to separate the safety boundary, create proper
> abstractions & write idiomatic Rust code.
Yeah, that approach works best when the interface surface is
small/simple enough relative to the functionality, e.g. the QR code
case we have in the kernel already.
So there are some use cases of the approach (codecs have also been
discussed as another one). But going, in the extreme, "function by
function" replacing C with Rust and having two-way calls everywhere
isn't good, and it isn't the goal.
Instead, we aim to write safe Rust APIs ("abstractions") and then
ideally having pure Rust modules that take advantage of those.
Sometimes you may want to keep certain pieces in C, but still use them
from the Rust module until you cover those too eventually.
> One good path forward using the reference driver would be to first
> create a read-only version. That was the plan that Wedson followed with
> ext2 (and IIRC also ext4? I might misremember). It apparently makes the
> initial implementation easier (I have no experience with filesystems)
> and thus works better as a PoC.
Yeah, my understanding is that a read-only version would be easier.
Performance is another axis too.
It would be nice to see eventually a 100% safe code Rust filesystem,
even if read-only and "slow". That could already have use cases.
(Wedson was planning read-writes ones too.)
(Thanks Benno!)
Cheers,
Miguel
