Eric Biggers <ebiggers3@xxxxxxxxx> 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? Yes. I can make that more explicit, say perhaps "... specify an extension to the size of the buffer". > 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 ...? It would have to work that way. I can put this in a comment for future guidance in the kernel header file if you'd prefer. > 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"? If someone decides not to read the documentation, one could argue they get what they deserve. > Maybe adding an extra "buffer size" argument to the syscall? This idea has already been rejected. > 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. One or more bits (probably just one) are tentatively reserved to indicate that the buffer is now bigger. How much bigger I cannot say at this point, not knowing the circumstances yet that will require the extension. David
