On Fri, Jun 20, 2025 at 8:10 PM Viacheslav Dubeyko <Slava.Dubeyko@xxxxxxx> wrote: > > I don't have plans to re-write the whole Linux kernel. :) Because, any > particular file system driver needs to interact with VFS, memory subsystem and > block layer. So, pure Rust implementation means that everything should be re- > written in Rust. But it's mission impossible any time soon. :) There is no need to do everything at once, but avoiding to write/use safe abstractions completely for common facilities is not the goal. But, to be clear, we are not suggesting rewriting VFS or others in Rust. As for "mission impossible", a couple filesystems were prototyped on top of the (read-only) VFS abstractions I linked. I am not saying the abstractions are complete or that it will be easy or that HFS (not even HFS+) is comparable to those or anything (I don't know), but you could check them out / try them to get a feeling for the approach. Others may be able to tell you more about their experience with those. > I am considering of re-writing HFS/HFS+ in Rust but still surviving in the C > implemented environment. I don't think that even VFS will be completely re- > written in Rust and adopted any time soon. So, I am talking only about HFS/HFS+ > "abstractions" now. Again, nobody suggested rewriting VFS etc.. It is about abstracting (using) existing C infrastructure. Please look at the patches I linked above. > Even if you have bugs in read path only, then end user will not have access to > data. As a result, end-user will think that data is lost anyway because the data > cannot be accessed. That is not what I meant. If you have bugs in your read path (or, generally, in the kernel), then you will have a big problem in both scenarios. That is not a difference. And, yes, you can have systems that end up losing data when fed with untrusted/garbage data, or a user could discard their original drive after thinking a copy was correct, and things like that. But when you also promise to do writes properly, that introduces complexity and new use cases -- you will have users saving new data and expecting that to be kept no matter what, you could corrupt existing unrelated data, and so on. > Also, anyway, C implementation and Rust implementation needs to co-exist, at > minimum, for some time, I assume. That depends on you as a maintainer, as well as what architectures your current users use and so on. But there are cases where Rust-only functionality is fine (which is easier to justify too). Thanks! Cheers, Miguel
