Re: [RFC PATCH 00/19] Rust abstractions for VFS

[Matthew Wilcox <willy@infradead.org>]

On Tue, Jan 09, 2024 at 03:25:11PM -0300, Wedson Almeida Filho wrote:
> On Wed, 3 Jan 2024 at 22:49, Matthew Wilcox <willy@infradead.org> wrote:
> > > What makes you characterize these filesystems as toys? The fact that
> > > they only use the file's inode in iterate_shared?
> >
> > They're not real filesystems.  You can't put, eg, root or your home
> > directory on one of these filesystems.
> 
> tarfs is a real file system, we use it to mount read-only container
> layers on top of dm-verity for integrity.

You're using it in production?  Oh dear.

> > > I'm trying to understand the argument here. Are saying that Rust
> > > cannot have different APIs with the same performance characteristics
> > > as C's, unless we also fix the C apis?
> > >
> > > That isn't even a requirement when introducing new C apis, why would
> > > it be a requirement for Rust apis?
> >
> > I'm saying that we have the current object orientation (eg each inode
> > is an object with inode methods) for a reason.  Don't change it without
> > understanding what that reason is.  And moving, eg iterate_shared() from
> > file_operations to struct file_system_type (effectively what you've done)
> > is something we obviously wouldn't want to do.
> 
> I don't think I'm changing anything. AFAICT, I'm adding a way to write
> file systems in Rust. It uses the C API faithfully -- if you find ways
> in which it doesn't, I'd be happy to fix them.

You are changing the _object model_.  The C API has separate objects
for inodes, files, filesystems, superblocks, dentries, etc, etc.  You've
just smashed all of it together into a FileSystem which implements all
of the inode, file, address_space, etc, etc ops.  And this is the wrong
approach.