On Sun Jun 22, 2025 at 12:38 AM CEST, Viacheslav Dubeyko wrote: > 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. Ah maybe this is where the misunderstanding originates: we're not talking about reimplementing bitmap or b-trees in Rust. We build abstractions that call into the C side and use the existing implementations. The abstractions make them available for the Rust side to use them safely & efficiently. In the case of bitmaps, there already is someone working on it, see [1]. In your metaphor, our recommendation is use adapters (the abstractions) to go from the existing house frame (C) to the new interior (Rust). And to avoid having mixed interior. [1]: https://lore.kernel.org/all/20250620082954.540955-1-bqe@xxxxxxxxxx --- Cheers, Benno
