[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161204043803.GA1022@ZenIV.linux.org.uk>
Date: Sun, 4 Dec 2016 04:38:05 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: David Howells <dhowells@...hat.com>
Cc: linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info
available [ver #3]
On Wed, Nov 23, 2016 at 12:55:51AM +0000, David Howells wrote:
> + * vfs_xgetattr - Get the enhanced basic attributes of a file
> + * @path: The file of interest
> + * @stat: Where to return the statistics
> + *
> + * Ask the filesystem for a file's attributes. The caller must have preset
> + * stat->request_mask and stat->query_flags to indicate what they want.
> + *
> + * If the file is remote, the filesystem can be forced to update the attributes
> + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags or can
> + * suppress the update by passing AT_NO_ATTR_SYNC.
> + *
> + * Bits must have been set in stat->request_mask to indicate which attributes
> + * the caller wants retrieving. Any such attribute not requested may be
> + * returned anyway, but the value may be approximate, and, if remote, may not
> + * have been synchronised with the server.
I understand wanting to avoid extra arguments, but you are asking for trouble
with that sort of calling conventions. Verifying that all call chains have
these fields initialized is bloody unpleasant and it *is* going to break,
especially since the rules are "you need to initialize it for vfs_xgetattr(),
but not for vfs_getattr()" - the names are similar enough for confusion,
and that's not the only such pair.
Powered by blists - more mailing lists