On Fri, 2025-06-20 at 00:24 +0200, Benno Lossin wrote: > 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). > > So, any file system driver is not isolated thing and it interacts with VFS and memory subsystem through a set of callbacks: struct file_operations; struct inode_operations; struct dentry_operations; struct address_space_operations; struct super_operations; struct fs_context_operations; struct file_system_type; Nowadays, VFS and memory subsystems are C implemented functionality. And I don't think that it will be changed any time soon. So, even file system driver will be completely re-written in Rust, then it should be ready to be called from C code. Moreover, file system driver needs to interact with block layer that is written in C too. So, glue code is inevitable right now. How bad and inefficient could be using the glue code? Could you please share some example? As far as I can see, it is possible to generalize HFS/HFS+ drivers to these "abstractions": (1) block bitmap - allocate_blocks() - free_blocks() (2) Catalog tree - find() - create() - delete() - rename() (3) Extents tree - get_block() - extend_file() - free_fork() - truncate_file() (4) B-tree - open() - close() - write() (5) B-tree node - find() - create() - clear() - copy() - move() - read() - write() It's not all abstractions and the possible API doesn't look yet complete and reasonable. But it is the basic blocks of HFS and HFS+ drivers. I think it needs to dive deeper in the current code state to elaborate the vision of other abstractions. Thanks, Slava.
