> On Mar 24, 2017, at 2:53 PM, Eric Biggers <ebiggers3@gmail.com> wrote:
> 
> On Tue, Mar 07, 2017 at 05:22:55PM +0000, David Howells wrote:
>> STATX_ALL	[All currently available stuff]
>> .TE
>> .in
>> .PP
>> .B "Do not"
>> simply set
>> .I mask
>> to UINT_MAX as one or more bits may, in future, be used to specify an extension
>> to the buffer.
> 
> To clarify, will an "extension to the buffer" be an increase in the size of
> struct statx?  I think it would have to be, otherwise programs filling a struct
> statx with STATX_ALL would start breaking as soon as they're rebuilt with the
> new value of STATX_ALL, no?  Or would these "extension to the buffer" bits not
> be added to STATX_ALL ...?

The value of STATX_ALL would match the size of struct statx in the header at
compilation time, so this would always be consistent.
> 
> And I don't suppose there's anything we can do to stop programs from asking
> for mask bits that haven't been defined yet, then breaking later if they
> happen to be defined as "extensions"?  Maybe adding an extra "buffer size"
> argument to the syscall?

You can't stop applications from doing dumb things, like asking to read 1MB
of data into a buffer that is only 512KB in size.  That will also work fine
as long as the application only reads a files smaller than 512KB.

Similarly, if the statx() API says that the STATX_ALL mask is the list of
currently-supported bits, but the app asks for more bits than it allocates
a buffer for, there isn't much that the kernel can do.

> I'm concerned that the idea of "extensions" isn't well thought out, and in
> practice we'll just be stuck with the current struct size (256 bytes) forever.

The extensions work exactly as they should - the client sets bits for fields
that it needs (and by definition it shouldn't ask for anything that it doesn't
understand), and the kernel masks this down to the bits that it understands.

If the client asks for more bits than the kernel understands, it is likely a
newer application on an older kernel, and it will only get back the fields
that the kernel understands.  The reverse (client asking for fewer bits than
the kernel understands) is normal behaviour for this interface.  The kernel should only fill in fields that the client requested and for which there is
space in the struct.

Cheers, Andreas