On Wed, 3 Jan 2024 at 15:02, Matthew Wilcox <willy@xxxxxxxxxxxxx> 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. What makes you characterize these filesystems as toys? The fact that they only use the file's inode in iterate_shared? > 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. 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? Cheers, -Wedson
