On Fri, 2025-06-20 at 10:17 +0200, Miguel Ojeda wrote: > On Thu, Jun 19, 2025 at 11:49 PM Viacheslav Dubeyko > <Slava.Dubeyko@xxxxxxx> wrote: > > > > But I would like to implement the step-by-step approach. > > Like Benno mentions, it is hard to say how it will look with your > description, i.e. how you plan to "cut" things. > > On one hand, it sounds like you don't plan to write VFS abstractions > -- did you check Wedson's work? > 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. :) > https://lore.kernel.org/rust-for-linux/20240514131711.379322-1-wedsonaf@xxxxxxxxx/ > > i.e. it sounds like you want to replace parts of e.g. HFS with Rust > code while still going through C interfaces at some places inside HFS, > and that has downsides. > On the other hand, you mention "abstractions" around VFS concepts too, > so you may have something else in mind. > 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. > > Frankly speaking, I don't see how Read-Only version can be easier. :) Because, > > even Read-Only version requires to operate by file system's metadata. And it's > > around 80% - 90% of the whole file system driver functionality. From my point of > > view, it is much easier to convert every metadata structure implementation step > > by step into Rust. > > Well, apart from having to write more operations/code, as soon as > there may be writers, you have to take care of that possibility in > everything you do, no? > > Worst of all, I imagine you have to test (and generally treat the > project) way more carefully, because now your users could lose real > data. > > 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. Any modification or bug fix in file system driver could result in real data loss even for C implementation. So, of course, we need to be really careful with re- writing file system driver in Rust. But if we have valid implementation in C then we need to follow the functional logic and make the Rust implementation consistent with logic in C. Also, we have xfstests that can help to check that functionality works correctly. Of course, xfstests cannot guarantee 100% correctness of file system operations. So, frankly speaking, I don't see big difference between Read-Only or Read-Write functionality. Because, both functionalities should be correct and could result in inconsistent state of file system's in-core metadata or what end-user can access or see, finally. Also, anyway, C implementation and Rust implementation needs to co-exist, at minimum, for some time, I assume. Thanks, Slava.
