On Thu Jun 19, 2025 at 11:39 PM CEST, Viacheslav Dubeyko wrote: > 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. I'd of course have to see the concrete code, but this sounds a lot like calling back and forth between C and Rust. Which will most likely be painful. But it did work for the QR code generator, so we'll see. >> [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 personally don't know how this argument works, I only cited it in case it is useful to people with domain knowledge :) >> > > 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? :) Yes! Everything that is used by other drivers/subsystems are usual candidates for abstractions. Essentially an abstraction is a rustified version of the C API. For example, `Mutex<T>` is generic over the contained value, uses guards and only allows access to the inner value if the mutex is locked. Abstractions can take a pretty different form from the C API when it's possible to make certain undesired uses of the API impossible through Rust's type system or other features (in the case of the mutex, making it impossible to access a value without locking it). Though they can also be pretty simple if the C API is straightforward (this of course depends on the concrete API). Their purpose is to encapsulate the C API and expose its functionality to safe Rust (note that calling any C function is considered `unsafe` in Rust). Calling C functions directly from Rust driver code (ie without going through an abstraction) is not something that we want to allow (of course there might be some exceptional cases where it is needed temporarily). And thus everything that you use should have an abstraction (this might include driver-specific abstractions that effectively are also part of the driver, but encapsulate the C parts, when you have converted the driver fully to rust, you probably won't need any of them). --- Cheers, Benno
