On Mon, Mar 06, 2017 at 01:49:56PM -0500, Jeff Layton wrote: > On Mon, 2017-01-09 at 11:25 +0000, David Howells wrote: > > Andreas Dilger <adilger@xxxxxxxxx> wrote: > > > > > David Howells has been working several years to get the statx() syscall > > > into the kernel, but it seems to perpetually be blocked by minor bikeshed > > > discussions. What is needed to finally get this landed? Can we agree > > > that the current (now very minimal and stripped-down) interface is OK > > > and just agree to land it? > > > > That would be great - but it mostly depends on Al at the moment. > > > > ...and it's now merged in v4.11, so I don't think we need to discuss > how to get this merged at LSF. > > What we may want to do is convert this into a discussion of other > topics related to statx: > > What criteria should we insist on for exposing new attributes via > statx? There was pushback about presenting dos attributes, which is why > I'm asking. > > What attributes that aren't exposed yet do we want to add next? I've > done some preliminary work to make i_version a bit more consistent > across filesystems, which seems like something that could be very > useful for applications. > > What about glibc support? Test coverage? Are those planned? There aren't any xfstests, and afaict there haven't been any proposed, at least not recently. The last time anyone inquired[1] about this, the only reply was that due to all the bikeshedding there weren't going to be any until after it lands. So, now that it's landed, where are there tests? I guess the file samples/statx/test-statx.c is the starting point? (So yes, we can argue about this at LSF. Or right here. :)) --D [1] https://lwn.net/Articles/707610/ > Once the dust settles from this merge, it might also be good to start > considering a bona-fide readdirplus interface. Has anyone given thought > as to what that should look like? > > -- > Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
