On Wed, Dec 13, 2023 at 09:57:22AM +1100, NeilBrown wrote: > On Wed, 13 Dec 2023, Kent Overstreet wrote: > > On Mon, Dec 11, 2023 at 11:40:16PM +0000, David Howells wrote: > > > Kent Overstreet <[email protected]> wrote: > > > > > > > I was chatting a bit with David Howells on IRC about this, and floated > > > > adding the file handle to statx. It looks like there's enough space > > > > reserved to make this feasible - probably going with a fixed maximum > > > > size of 128-256 bits. > > > > > > We can always save the last bit to indicate extension space/extension > > > record, > > > so we're not that strapped for space. > > > > So we'll need that if we want to round trip NFSv4 filehandles, they > > won't fit in existing struct statx (nfsv4 specs 128 bytes, statx has 96 > > bytes reserved). > > > > Obvious question (Neal): do/will real world implementations ever come > > close to making use of this, or was this a "future proofing gone wild" > > thing? > > I have no useful data. I have seen lots of filehandles but I don't pay > much attention to their length. Certainly some are longer than 32 bytes. > > > > > Say we do decide we want to spec it that large: _can_ we extend struct > > statx? I'm wondering if the userspace side was thought through, I'm > > sure glibc people will have something to say. > > The man page says: > > Therefore, do not simply set mask to UINT_MAX (all bits set), as > one or more bits may, in the future, be used to specify an > extension to the buffer. > > I suspect the glibc people read that.
The trouble is that C has no notion of which types are safe to pass across a dynamic library boundary, so if we increase the size of struct statx and someone's doing that things will break in nasty ways.
