On Wed, 10 Jan 2024 14:19:41 -0500 Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > On Wed, Jan 10, 2024 at 09:19:37AM +1100, Dave Chinner wrote: >> On Tue, Jan 09, 2024 at 07:25:38PM +0000, Matthew Wilcox wrote: >> > On Tue, Jan 09, 2024 at 04:13:15PM -0300, Wedson Almeida Filho wrote: >> > > On Wed, 3 Jan 2024 at 17:41, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> > > > No. This "cleaner version on the Rust side" is nothing of that sort; >> > > > this "readdir doesn't need any state that might be different for different >> > > > file instances beyond the current position, because none of our examples >> > > > have needed that so far" is a good example of the garbage we really do >> > > > not need to deal with. >> > > >> > > What you're calling garbage is what Greg KH asked us to do, namely, >> > > not introduce anything for which there are no users. See a couple of >> > > quotes below. >> > > >> > > https://lore.kernel.org/rust-for-linux/2023081411-apache-tubeless-7bb3@gregkh/ >> > > The best feedback is "who will use these new interfaces?" Without that, >> > > it's really hard to review a patchset as it's difficult to see how the >> > > bindings will be used, right? >> > > >> > > https://lore.kernel.org/rust-for-linux/2023071049-gigabyte-timing-0673@gregkh/ >> > > And I'd recommend that we not take any more bindings without real users, >> > > as there seems to be just a collection of these and it's hard to >> > > actually review them to see how they are used... >> > >> > You've misunderstood Greg. He's saying (effectively) "No fs bindings >> > without a filesystem to use them". And Al, myself and others are saying >> > "Your filesystem interfaces are wrong because they're not usable for real >> > filesystems". >> >> And that's why I've been saying that the first Rust filesystem that >> should be implemented is an ext2 clone. That's our "reference >> filesystem" for people who want to learn how filesystems should be >> implemented in Linux - it's relatively simple but fully featured and >> uses much of the generic abstractions and infrastructure. >> >> At minimum, we need a filesystem implementation that is fully >> read-write, supports truncate and rename, and has a fully functional >> userspace and test infrastructure so that we can actually verify >> that the Rust code does what it says on the label. ext2 ticks all of >> these boxes.... > > I think someone was working on that? But I'd prefer that not to be a > condition of merging the VFS interfaces; we've got multiple new Rust > filesystems being implemented and I'm also planning on merging Rust > bcachefs code next merge window. It's very far from a fully functional clone of ext2 but the following can do simple read-write to/from files and directories: https://github.com/fujita/linux/tree/ext2-rust/fs/ext2rust For now, all of the code is unsafe Rust, using C structures directly but I could update the code to see how well Rust VFS abstractions for real file systems work.
