On Wed, Feb 07, 2024 at 03:57:35PM -0500, Kent Overstreet wrote: > On Wed, Feb 07, 2024 at 12:06:05PM +0100, Miguel Ojeda wrote: > > On Wed, Feb 7, 2024 at 6:57 AM Thomas Bertschinger > > <tahbertschinger@xxxxxxxxx> wrote: > > > > > > This series adds support for Rust code into bcachefs. This only enables > > > using Rust internally within bcachefs; there are no public Rust APIs > > > added. Rust support is hidden behind a new config option, > > > CONFIG_BCACHEFS_RUST. It is optional and bcachefs can still be built > > > with full functionality without rust. > > > > But is it the goal to make it use Rust always? If not, do you mean you > > are you going to have 2 "modes" in bcachefs? i.e. one with all C, and > > one with some parts replaced (i.e. duplicated) in Rust? > > > > If it is the former (dropping C), then please note that it will limit > > where bcachefs can be built for, i.e. architectures and configurations > > (at least for the time being, i.e. we want to relax all that, but it > > will take time). 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. > > If it is the latter (duplication), then please note that the kernel > > has only gone the "duplication" route for "Rust reference drivers" as > > an exceptional case that we requested to bootstrap their subsystems > > and give Rust a try. > > > > Could you please explain more about what is the intention here? > > I think we're still at the "making sure everything works" stage. > > I'll try to keep Rust optional a release or two, more so that we can > iron out any toolchain hiccups, and in that period we'll be looking for > non critical stuff to transition to Rust (the debugfs code, most > likely). > > When we make Rust a hard dependency kernel side will have to be a topic > of discussion - but Rust is already a hard dependency on the userspace > side, in -tools, so the lack of full architecture support is definitely > something I'm hoping get addressed sooner rather than later, but it's > probably not the blocker here. > As soon as we're ok with making Rust a hard dependency kernel side, > we'll be looking at switching a lot of stuff to Rust (e.g. fsck). > > > Either way, the approach you are taking in this patch series seems to > > be about calling C code directly, rather than writing and using > > abstractions in general. For instance, in one of the patches you > > mention in a comment "If/when a Rust API is provided" to justify the > > functions, but it is the other way around, i.e. you need to first > > write the abstractions for that C code, upstream them through the > > relevant tree/maintainers, and then you use them from your Rust code. > > I didn't see that comment, but we're mainly looking at what we can do > inside fs/bcachefs/, and I've already got Rust bindings for the btree > interface (that I talked about in a meeting with you guys, actually) > that we'll be pulling in soon. Personally, I suspect that converting the existing big-glob-of-C fs implementations is going to be a long slow task of rewriting the C code piece by testable piece, starting with the outer rings and moving in towards the core. Until the core is done, there's probably going to be a lot of FFI'ing going on. I think that's what Kent is getting at when he talks about rewriting online fsck before moving on to the guts of bcachefs. Or at least, that's the approach I would take if I were to start converting XFS. Messing around with core structures like xfs_inode and xfs_mount will come muuuuch later. > > 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. > > > I wasn't sure if this needed to be an RFC based on the current status > > > of accepting Rust code outside of the rust/ tree, so I designated it as > > > such to be safe. However, Kent plans to merge rust+bcachefs code in the > > > 6.9 merge window, so I hope at least the first 2 patches in this series, > > > the ones that actually enable Rust for bcachefs, can be accepted. > > > > This is worrying -- there has been no discussion about mixing C and > > Rust like this, but you say it is targeted for 6.9. I feel there is a > > disconnect somewhere. Perhaps it would be a good idea to have a quick > > meeting about this. > > Oh? This is exactly what I said we were going to do at the conference :) > > Happy to meet though, let's figure out a time that works for Thomas too. Honestly, these three patches seem to me like the barest stub to be able to plant a flag and say "Hey look, Rust in a merged linux fs driver!" Even if the only progress anyone makes on that this year is to wrap the bcachefs btree iterators in Rust and reimplement a bunch of ioctls. --D > Cheers, > Kent >
