[LSF/MM TOPIC] getting statx() syscall merged

[LSF/MM TOPIC] getting statx() syscall merged

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

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?

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [LSF/MM TOPIC] getting statx() syscall merged

[David Howells]

Andreas Dilger <adilger@dilger.ca> 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.

David

Re: [Lsf-pc] [LSF/MM TOPIC] getting statx() syscall merged

[Jeff Layton]

On Mon, 2017-01-09 at 11:25 +0000, David Howells wrote:
> Andreas Dilger <adilger@dilger.ca> 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?

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@poochiereds.net>

Re: [Lsf-pc] [LSF/MM TOPIC] getting statx() syscall merged

[Darrick J. Wong]

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@dilger.ca> 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@poochiereds.net>