On Thu, 2025-06-19 at 21:33 +0200, Benno Lossin wrote: > 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. > Yeah, makes sense to me. It's one of the possible way. And I would like to have as C as Rust implementation of driver as the first step. But it's hard enough to implement everything at once. So, I would like to follow the step by step approach. > 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. > This is what I am considering as the first step. As far as I can see, HFS and HFS+ have "duplicated" functionality with some peculiarities on every side. So, I am considering to have something like Rust "library" that can absorb this "duplicated" fuctionality at first. As a result, HFS and HFS+ C code can re-use the Rust "library" at first. Finally, the whole driver(s) could be converted into the Rust implementation. > [1]: https://rust-for-linux.com/rust-reference-drivers > Thanks for sharing this. > > > 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 see your point but even Read-Only functionality is too much. :) Because, it needs to implement 80% - 90% functionality of metadata management even for Read- Only case. And I would like to make the whole thing done by small working steps. This is why I would like: (1) start from Rust "library", (2) move metadata management into Rust "library" gradually, (3) convert the whole driver into Rust implementation. > > > 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. > Sounds great! :) I really need some help and advice. > 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! > Sounds interesting! Let me prepare my questions. :) So, HFS/HFS+ have superblock, bitmap, b-trees, extent records, catalog records. It sounds to me like candidates for abstractions. Am I correct here? Are we understand abstraction at the same way? :) Thanks, Slava.
