> > What I'm saying is that read and write are _no_more_ related to the > > file than fstat. Read/write operate on inode data, fstat operates on > > inode metadata. > > The read and write operations are DEFINITELY related to the file descriptor > because of f_pos. Each process opening the same file can have a different > f_pos so read/write will work in different locations of the file.
Ah yes, but f_pos is handled entirely within the VFS. The filesystem has nothing to do with f_pos, and the read/write methods are passed the offset explicitly. So with that the read/write calls (for regular files at least) really are not that different from fstat. > In contrast getattr and getxattr operate on the single inode and you don't > get e.g. a different i_size or i_uid or i_gid depending on who opened a > file, nor is the xattr different. You won't get different data either (again for regular files). Yet passing file operations down to the filesystem implementation makes sense even for regular files, even if for most filesystems we could get away with a totally stateless read/write model (as some other OS's apparently do). What I'm arguing, is that if we pass the open file for read/write to the filesystem for regular files, it makes _equally_ as much sense to pass the open file for getattr/setattr/xattr operations. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html