[rulkc] [RFC] Should we consider to re-write HFS/HFS+ in Rust?
Dmitry Rokosov
ddrokosov at salutedevices.com
Wed Jun 11 12:27:37 MSK 2025
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
More information about the rulkc
mailing list