On Fri, 2025-06-20 at 20:11 +0200, Miguel Ojeda wrote: > On Fri, Jun 20, 2025 at 7:50 PM Viacheslav Dubeyko > <Slava.Dubeyko@xxxxxxx> wrote: > > > > 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. > > That is fine and expected. > > > 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? > > Please take a look the proposed VFS abstractions, the filesystems that > were prototyped on top of them, and generally other Rust code we have. > > As for "how bad", the key is that every time you go through a C > signature, you need to constrain yourself to what C can encode (which > is not much), use unsafe code and other interop issues. Thus you want > to avoid having to go back and forth all the time. > > Thus, the idea is to write the filesystem in Rust using abstractions > that shield you from that. > > Cc'ing other potentially interested/related people. > I completely see your point. But let's consider allegory of home construction. Usually, we need to start from foundation, then we need to raise the walls, and so on. The file system's metadata is the foundation and if I would like to re- write the file system driver, then I need to start from metadata. It means that it makes sense to re-write, for example, bitmap or b-tree functionality and to check that it works completely functionally correct in the C implemented environment. Then, potentially, I could switch on bitmap implementation in Rust. This is the vision of step-by-step implementation. And I completely OK with glue code and inefficiency on the first steps because I need to prepare the file system "foundation" and "walls". Also, I would like to manage the complexity of implementation and bug fix. It means that I would like to isolate the bugs in HFS/HFS+ layer. I can trust to C implementation of VFS but I cannot trust to Rust implementation of VFS. So, I prefer to re-write HFS/HFS+ functionality in Rust by using the C implemented environment at first. Because, from my point of view, it is the way to manage complexity and to isolate bugs by HFS/HFS+ layer only. And when everything will be in Rust, then it will be possible to switch on complete Rust environment. Thanks, Slava.
