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 ...? 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? 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. - Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
