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

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

Andreas Hindborg will most likely reply with some more info in the near
future, but I'll drop some of my thoughts.

On Wed May 28, 2025 at 6:16 PM CEST, Viacheslav Dubeyko wrote:
> On Wed, 2025-05-28 at 20:40 +0800, Yangtao Li wrote:
>> +cc rust-for-linux
>> 
>> 在 2025/5/28 07:39, Viacheslav Dubeyko 写道:
>> > Hi Adrian, Yangtao,
>> > 
>> > One idea crossed my mind recently. And this is about re-writing HFS/HFS+ in
>> > Rust. It could be interesting direction but I am not sure how reasonable it
>> > could be. From one point of view, HFS/HFS+ are not critical subsystems and we
>> > can afford some experiments. From another point of view, we have enough issues
>> > in the HFS/HFS+ code and, maybe, re-working HFS/HFS+ can make the code more
>> > stable.
>> > 
>> > I don't think that it's a good idea to implement the complete re-writing of the
>> > whole driver at once. However, we need a some unification and generalization of
>> > HFS/HFS+ code patterns in the form of re-usable code by both drivers. This re-
>> > usable code can be represented as by C code as by Rust code. And we can
>> > introduce this generalized code in the form of C and Rust at the same time. So,
>> > we can re-write HFS/HFS+ code gradually step by step. My point here that we
>> > could have C code and Rust code for generalized functionality of HFS/HFS+ and
>> > Kconfig would define which code will be compiled and used, finally.
>> > 
>> > How do you feel about this? And can we afford such implementation efforts?
>> 
>> It must be a crazy idea! Honestly, I'm a fan of new things.
>> If there is a clear path, I don't mind moving in that direction.
>> 
>
> Why don't try even some crazy way. :)

There are different paths that can be taken. One of the easiest would be
to introduce a rust reference driver [1] for HFS. The default config
option would still be the C driver so it doesn't break users (& still
allows all supported architectures), but it allows you to experiment
using Rust. Eventually, you could remove the C driver when ggc_rs is
mature enough or only keep the C one around for the obscure
architectures.

If you don't want to break the duplicate drivers rule, then I can expand
a bit on the other options, but honestly, they aren't that great:

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.

[1]: https://rust-for-linux.com/rust-reference-drivers

>> It seems that downstream already has rust implementations of puzzle and 
>> ext2 file systems. If I understand correctly, there is currently a lack 
>> of support for vfs and various infrastructure.
>> 
>
> Yes, Rust implementation in kernel is slightly complicated topic. And I don't
> suggest to implement the whole HFS/HFS+ driver at once. My idea is to start from
> introduction of small Rust module that can implement some subset of HFS/HFS+
> functionality that can be called by C code. It could look like a library that
> HFS/HFS+ drivers can re-use. And we can have C and Rust "library" and people can
> select what they would like to compile (C or 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.

>> I'm not an expert on Rust, so it would be great if some Rust people 
>> could share their opinions.
>> 
>
> I hope that Rust people would like the idea. :)

I'm sure that several Rust folks would be interested in getting their
hands dirty helping with writing abstractions and/or the driver itself.

I personally am more on the Rust side of things, so I could help make
the abstractions feel idiomatic and ergonomic.

Feel free to ask any follow up questions. Hope this helps!

---
Cheers,
Benno