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

[Viacheslav Dubeyko]

On Wed, 2025-06-11 at 12:27 +0300, Dmitry Rokosov wrote:
> 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?
> 

Even I didn't follow to HFS/HFS+ development because the active phase
was more than 20 years ago. :) The HFS/HFS+ code maintainership was
dead more than 10 years already. I tried to contribute to HFS/HFS+ 10
years ago and it was really sad experience.

The main use-case of HFS/HFS+ file system(s) was and is of mounting and
accessing under Linux file system volumes that was created and filled
by data under Mac OS X. I don't think that anybody now would like to
use HFS/HFS+ file system as rootfs or regular data partition under
Linux. Also, John Paul Adrian Glaubitz shared this "We definitely need
this driver to stay for Debian Ports as otherwise we won't be able to
boot PowerMacs using GRUB. GRUB won't be usable anymore on PowerMacs
with HFS/HFS+ being removed from the kernel.".

And this is exactly the point. The HFS/HFS+ is not critical subsystems
in the kernel and it can be easily re-written in Rust without
significant confrontation. Technically speaking, potentially, HFS/HFS+
could be the first Linux kernel file system driver(s) re-written in
Rust. I am a HFS/HFS+ maintainer in Linux kernel and I am ready to
support and promote the Rust implementation of HFS/HFS+ in Linux
kernel.

> 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+?
> 

The HFS/HFS+ are tiny file system drivers compared with other Linux
kernel file systems. However, I don't want to re-write the whole HFS or
HFS+ driver in Rust at once. The both HFS and HFS+ drivers have a lot
of shared logic that is duplicated in both drivers. So, I would like to
see at first something like Rust "library" that both HFS and HFS+
drivers could use by calling shared functionality. Finally, as the
second step, we could have Rust implementation of the whole driver.
And, as the maintainer, I would like to find Rust guys that could be
interested to implement such functionality for HFS/HFS+ because it
looks like promoting new technologies in Linux kernel. And, HFS/HFS+
could benefit from memory-safety features of Rust.

Thanks,
Slava. 

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