Thread (1 message) 1 message, 1 author, 2012-04-27

Re: [PATCH 0/6] Extended file stat system call

From: Myklebust, Trond <hidden>
Date: 2012-04-27 00:30:30
Also in: linux-cifs, linux-ext4, linux-fsdevel, linux-nfs

On Thu, 2012-04-26 at 22:57 +0100, David Howells wrote:
Myklebust, Trond [off-list ref] wrote:
quoted
You are still not explaining why they need to know the values at all? If
the values are bogus, then don't return them, and don't set the flag
that says they are being returned.
th
What if the xstat() and struct xstat eventually becomes what userspace uses as
stat() (as a wrapper) and struct stat (if such a thing is possible with glibc
versioning)?  Do older programs that think they're using stat() and don't know
about the extra fields available expect to see a useful value in st_ino?
Does it really matter whether it is the kernel or userland that is
responsible for faking up inode numbers? If userland wants to use
xstat() in order to fake up a stat() call, then it gets to take
responsibility for the results.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help