> > What I'm saying is that read and write are _no_more_ related to the
quoted text
> > 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.

quoted text
> 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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/