On Wed, Feb 7, 2024 at 5:39 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > [..] > Which architectures are supported by RoL at this point? > > I can't speak for kmo, but bcachefs is new(ish) to the kernel, and > restricting support to the five major 64-bit arches (x64, arm64, ppc64, > s390x, riscv64) might be quite a load off him and his team. > > Just speaking for myself, where xfs gets occasional weird bug reports of > strange behavior on platforms that none of us can test (csky) or OOM > reports with multi-TB filesystems on m68k. 6.7 only has x86. Loongarch is in for 6.8, aarch64 [1] and riscv [2] shouldn't be too far away, and there has been some interest in the IBM targets but they haven't sent anything yet. Any of Rust's tier 2 targets [3] should be reasonably feasible to support at some point if the maintainers are interested. csky and m68k are both tier 3 targets so less likely anytime soon, anything more niche than tier 3 will need GCC support. Which isn't terribly far off... [1]: https://lore.kernel.org/rust-for-linux/20231020155056.3495121-1-Jamie.Cunliffe@xxxxxxx/ [2]: https://lore.kernel.org/rust-for-linux/20230307102441.94417-1-conor.dooley@xxxxxxxxxxxxx/ [3]: https://doc.rust-lang.org/beta/rustc/platform-support.html > > > Instead, to bootstrap things, what about writing a bcachefs module in > > > Rust that uses e.g. the VFS abstractions posted by Wedson, and > > > perhaps, to experiment/prototype, fill it with calls to the relevant C > > > parts of bcachefs? That way you can start working on the abstractions > > > and code you will eventually need for a Rust bcachefs module, without > > > limiting what C bcachefs can do/build for. And that way it would also > > > help to justify the upstreaming of the VFS abstractions too, since you > > > would be another expected user of them, and so on. > > > > You mean a new, from scratch bcachefs module? Sorry, but that would not > > be practical :) > > > > Wedson's work is on my radar too - that opens up a lot of possibilities. > > But right now my goal is just to get /some/ Rust code into bcachefs, > > and make sure we can incrementally bring in more Rust code within the same > > module. > > Is the ultimate goal of the RoL project to build Rust wrappers around > the C filesystem objects? Or to design something more Rustic(?) and > present the interfaces that the VFS wants to the VFS only as needed? > > I might be talking nonsense here, I've only started learning Rust. But > I /can/ speculate about what a Rust fs will need based on all the stuff > I've learned over the past 20y of wrangling the C filesystems. > [..] The current approach is: 1. Raw bindings to needed APIs are autogenerated with bindgen 2. Abstractions are written on top of the bindings. These should provide a safe interface where, as much as possible, you can't accidentally misuse them to do something "wrong" (no UB by Rust's definitions, plus a fair bit of functional safety). 3. Modules use abstractions, no C bindings directly So Rust code is currently strictly a consumer of public core APIs, which cuts off at the module boundary. No reason there couldn't also be some core functionality, but there is a pretty strong goal of not keeping duplicate logic between Rust and C. Just not much of a use case yet. It works out best if bcachefs uses the same model, so future code can make use of whatever abstractions come along - at least for the core APIs, I can imagine bcache-c to bcache-rust will look different. There is a reasonably complete VFS abstraction available [4] (looks like you know of this already). I keep a loose list of what is being worked on, for any other interfaces needed [5]. - Trevor [4]: https://lore.kernel.org/rust-for-linux/20231018122518.128049-1-wedsonaf@xxxxxxxxx/#t [5]: https://github.com/tgross35/RFL-patch-registry/
