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

[Dmitry Rokosov]

Hello Viacheslav,

Thank you for placing your ideas to RULKC mailing list.
Please see my thought below.

On Tue, Jun 10, 2025 at 05:26:58PM -0700, Viacheslav Dubeyko wrote:
> Hello,
> 
> 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?

I followed the development of HFS/HFS+ a long time ago, but AFAIK, this
filesystem is now considered legacy from Apple's perspective.  Out of
curiosity, do you know of any real-world use cases for HFS/HFS+ outside
of older macOS versions?

Also, I found a Rust filesystem (FS) example that demonstrates possible
interactions with the VFS. Would that be sufficient to completely
rewrite a large filesystem like HFS/HFS+?

https://github.com/Rust-for-Linux/linux/blob/rust/samples/rust/rust_fs.rs

[...]

-- 
Thank you,
Dmitry