On Wed, Jan 03, 2024 at 06:02:40PM +0000, Matthew Wilcox wrote: > On Tue, Oct 31, 2023 at 05:14:08PM -0300, Wedson Almeida Filho wrote: > > > Also, I see you're passing an inode to read_dir. Why did you decide to > > > do that? There's information in the struct file that's either necessary > > > or useful to have in the filesystem. Maybe not in toy filesystems, but eg > > > network filesystems need user credentials to do readdir, which are stored > > > in struct file. Block filesystems store readahead data in struct file. > > > > Because the two file systems we have don't use anything from `struct > > file` beyond the inode. > > > > Passing a `file` to `read_dir` would require us to introduce an > > unnecessary abstraction that no one uses, which we've been told not to > > do. > > > > There is no technical reason that makes it impractical though. We can > > add it when the need arises. > > Then we shouldn't merge any of this, or even send it out for review > again until there is at least one non-toy filesystems implemented. > Either stick to the object orientation we've already defined (ie > separate aops, iops, fops, ... with substantially similar arguments) > or propose changes to the ones we have in C. Dealing only with toy > filesystems is leading you to bad architecture. Not sure I agree - this is a "waterfall vs. incremental" question, and personally I would go with doing things incrementally here. We don't need to copy the C interface as is; we can use this as an opportunity to incrementally design a new API that will obviously take lessons from the C API (since it's wrapping it), but it doesn't have to do things the same and it doesn't have to do everything all at once. Anyways, like you alluded to the C side is a bit of a mess w.r.t. what's in a_ops vs. i_ops, and cleaning that up on the C side is a giant hassle because then you have to fix _everything_ that implements or consumes those interfaces at the same time. So instead, it would seem easier to me to do the cleaner version on the Rust side, and then once we know what that looks like, maybe we update the C version to match - or maybe we light it all on fire and continue with rewriting everything in Rust... *shrug*
