RE: [RFC] Should we consider to re-write HFS/HFS+ in Rust?

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

On Thu, 2025-06-19 at 22:22 +0200, Miguel Ojeda wrote:
> On Thu, Jun 19, 2025 at 9:35 PM Benno Lossin <lossin@kernel.org> 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.
> 

Yeah, I completely agree. But I would like to implement the step-by-step
approach. At first, introduce a Rust "library" that will absorb a "duplicated"
functionality of HFS/HFS+. And C code of HFS/HFS+ will re-use the functionality
of Rust "library". Then, elaborate "abstractions" (probably, HFS/HFS+ metadata
primitives) and test it in Rust "library" by calling from C code. And, finally,
completely switch to Rust implementation.

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

Frankly speaking, I don't see how Read-Only version can be easier. :) Because,
even Read-Only version requires to operate by file system's metadata. And it's
around 80% - 90% of the whole file system driver functionality. From my point of
view, it is much easier to convert every metadata structure implementation step
by step into Rust.

Thanks,
Slava.