Thread (2 messages) 2 messages, 2 authors, 2018-10-18

Re: statx(2) API and documentation

flat view

From: Miklos Szeredi <miklos@szeredi.hu>
Date: 2018-10-18 15:42:01
Also in: linux-fsdevel, lkml

On Thu, Oct 18, 2018 at 9:39 AM, Florian Weimer [off-list ref] wrote:
* Miklos Szeredi:
quoted
On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer [off-list ref] wrote:
quoted
* Andreas Dilger:
quoted
quoted
So what's the point exactly?
Ah, I see your point...  STATX_ALL seems to be mostly useful for the kernel
to mask off flags that it doesn't currently understand.  It doesn't make
much sense for applications to specify STATX_ALL, since they don't have any
way to know what each flag means unless they are hard-coded to check each of
the STATX_* flags individually.  They should build up a mask of STATX_* flags
based on what they care about (e.g. "find" should only request attributes
based on the command-line options given).
Could you remove it from the UAPI header?  I didn't want to put it
into the glibc header, but was overruled.
To summarize Linus' rule of backward incompatibility: you can do it as
long as nobody notices.  So yeah, we could try removing STATX_ALL from
the uapi header, but we'd have to put it back in, once somebody
complains.
I don't recall a rule about backwards-incompatible API changes.  This
wouldn't impact ABI at all.
Right, API rules maybe are softer.   I'll do some patches...

Thanks,
Miklos
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help