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?
