On Wed, 3 Jan 2024 at 22:49, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Wed, Jan 03, 2024 at 04:04:26PM -0300, Wedson Almeida Filho wrote: > > 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? > > 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. The root of a container is made of potentially several of these layers, overlaid with overlayfs. We use this in confidential kata containers where we need to enforce authenticity and integrity of data: with tarfs, the original tar file is exposed to confidential VMs, so we can use existing signatures to verify that an attacker hasn't modified the data before the container starts, and dm-verity ensures that we catch any attempts by the host to change data after the container is running. > > > 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? > > 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. To show its usefulness, I'm providing a real file system that uses it, is simpler than the C version, and contains no unsafe code. So barring bugs in the abstractions, it contains no memory safety issues. Why do you feel I need to mimic the unsafe (in the sense that the compiler doesn't help you prevent safety issues) way C does it _now_? Cheers, -Wedson
