Hi Adrian, On Wed, 2025-05-28 at 09:11 +0200, John Paul Adrian Glaubitz wrote: > Hi Slava, > > On Tue, 2025-05-27 at 23:39 +0000, Viacheslav Dubeyko wrote: > > 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 am generally not opposed to rustifying parts of the Linux kernel. However, I > would still postpone such efforts into the future until the Rust frontend in > GCC has become usable on all architectures supported by the kernel such that > rustifying a kernel module does not result in it becoming unusable on architectures > without a native rustc compiler. > This is why I am considering Rust implementation as parallel to C implementation. The Rust and C implementations can co-exist at the same time and people can decide which implementation they would like to compile. And we can do such implementation gradually by introducing small pieces of functionality. Maybe, it can involve Rust people into HFS/HFS+ development process. Thanks, Slava.
