Re: [RFC PATCH 10/19] rust: fs: introduce `FileSystem::read_folio`

[Al Viro <viro@zeniv.linux.org.uk>]

On Tue, Nov 07, 2023 at 09:35:44PM -0300, Wedson Almeida Filho wrote:

> > While we are at it, lookup is also very much not a per-filesystem operation.
> > Take a look at e.g. procfs, for an obvious example...
> 
> The C api offers the greatest freedom: one could write a file system
> where each file has its own set of mapping_ops, inode_ops and
> file_ops; and while we could choose to replicate this freedom in Rust
> but we haven't.

Too bad.
 
> Mostly because we don't need it, and we've been repeatedly told (by
> Greg KH and others) not to introduce abstractions/bindings for
> anything for which there isn't a user. Besides being a longstanding
> rule in the kernel, they also say that they can't reasonably decide if
> the interfaces are good if they can't see the users.

The interfaces are *already* there.  If it's going to be a separate
set of operations for Rust and for the rest of the filesystems, we
have a major problem right there.

> The existing Rust users (tarfs and puzzlefs) only need a single
> lookup. And a quick grep (git grep \\\.lookup\\\> -- fs/) appears to
> show that the vast majority of C filesystems only have a single lookup
> as well. So we choose simplicity, knowing well that we may have to
> revisit it in the future if the needs change.
> 
> > Wait a minute... what in name of everything unholy is that thing doing tied
> > to inodes in the first place?
> 
> For the same reason as above, we don't need it in our current
> filesystems. A bunch of C ones (e.g., xfs, ext2, romfs, erofs) only
> use the dentry to get the name and later call d_splice_alias(), so we
> hide the name extraction and call to d_splice_alias() in the
> "trampoline" function.

What controls the lifecycle of that stuff from the Rust point of view?