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
