On Wed, Jan 24, 2024 at 10:08:35PM +0900, FUJITA Tomonori wrote: > 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. I think that would be well received. I think the biggest hurdle for a lot of people is going to be figuring out the patterns for expressing old idioms in safe rust - a version of ext2 in safe Rust would be the perfect gentle introduction for filesystem people. And if it achieved feature parity with fs/ext2, there'd be a strong argument for it eventually replacing fs/ext2 so that we can more safely mount untrusted filesystem images.
