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

["Benno Lossin" <lossin@kernel.org>]

On Sun Jun 22, 2025 at 12:38 AM CEST, Viacheslav Dubeyko wrote:
> On Fri, 2025-06-20 at 20:11 +0200, Miguel Ojeda wrote:
>> On Fri, Jun 20, 2025 at 7:50 PM Viacheslav Dubeyko
>> <Slava.Dubeyko@ibm.com> wrote:
>> > 
>> > Nowadays, VFS and memory subsystems are C implemented functionality. And I don't
>> > think that it will be changed any time soon. So, even file system driver will be
>> > completely re-written in Rust, then it should be ready to be called from C code.
>> 
>> That is fine and expected.
>> 
>> > Moreover, file system driver needs to interact with block layer that is written
>> > in C too. So, glue code is inevitable right now. How bad and inefficient could
>> > be using the glue code? Could you please share some example?
>> 
>> Please take a look the proposed VFS abstractions, the filesystems that
>> were prototyped on top of them, and generally other Rust code we have.
>> 
>> As for "how bad", the key is that every time you go through a C
>> signature, you need to constrain yourself to what C can encode (which
>> is not much), use unsafe code and other interop issues. Thus you want
>> to avoid having to go back and forth all the time.
>> 
>> Thus, the idea is to write the filesystem in Rust using abstractions
>> that shield you from that.
>> 
>> Cc'ing other potentially interested/related people.
>> 
>
> I completely see your point. But let's consider allegory of home construction.
> Usually, we need to start from foundation, then we need to raise the walls, and
> so on. The file system's metadata is the foundation and if I would like to re-
> write the file system driver, then I need to start from metadata. It means that
> it makes sense to re-write, for example, bitmap or b-tree functionality and to
> check that it works completely functionally correct in the C implemented
> environment. Then, potentially, I could switch on bitmap implementation in Rust.
> This is the vision of step-by-step implementation. And I completely OK with glue
> code and inefficiency on the first steps because I need to prepare the file
> system "foundation" and "walls". Also, I would like to manage the complexity of
> implementation and bug fix. It means that I would like to isolate the bugs in
> HFS/HFS+ layer. I can trust to C implementation of VFS but I cannot trust to
> Rust implementation of VFS. So, I prefer to re-write HFS/HFS+ functionality in
> Rust by using the C implemented environment at first. Because, from my point of
> view, it is the way to manage complexity and to isolate bugs by HFS/HFS+ layer
> only. And when everything will be in Rust, then it will be possible to switch on
> complete Rust environment.

Ah maybe this is where the misunderstanding originates: we're not
talking about reimplementing bitmap or b-trees in Rust. We build
abstractions that call into the C side and use the existing
implementations. The abstractions make them available for the Rust side
to use them safely & efficiently.

In the case of bitmaps, there already is someone working on it, see [1].

In your metaphor, our recommendation is use adapters (the abstractions)
to go from the existing house frame (C) to the new interior (Rust). And
to avoid having mixed interior.

[1]: https://lore.kernel.org/all/20250620082954.540955-1-bqe@google.com

---
Cheers,
Benno