From: Florian Weimer <fw@deneb.enyo.de>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Andreas Dilger <adilger@dilger.ca>,
Michael Kerrisk <mtk.manpages@gmail.com>,
David Howells <dhowells@redhat.com>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: statx(2) API and documentation
Date: Thu, 18 Oct 2018 09:39:21 +0200 [thread overview]
Message-ID: <87sh13ya8m.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <CAJfpegscdd7Q7waB4me7RMC_SJv4=rQwEGXBYNGAr2F3WE5=zA@mail.gmail.com> (Miklos Szeredi's message of "Thu, 18 Oct 2018 09:37:44 +0200")
* Miklos Szeredi:
> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * Andreas Dilger:
>>
>>>> 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.
next prev parent reply other threads:[~2018-10-18 7:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-17 18:24 statx(2) API and documentation Miklos Szeredi
2018-10-17 18:45 ` Andreas Dilger
2018-10-17 19:04 ` Miklos Szeredi
2018-10-17 20:22 ` Andreas Dilger
2018-10-17 22:22 ` Florian Weimer
2018-10-18 7:37 ` Miklos Szeredi
2018-10-18 7:39 ` Florian Weimer [this message]
2018-10-18 7:42 ` Miklos Szeredi
2018-10-18 7:23 ` Miklos Szeredi
2018-10-17 22:15 ` Amir Goldstein
2018-10-18 7:41 ` Jan Kara
2018-10-18 7:49 ` Florian Weimer
2018-10-18 7:49 ` Florian Weimer
2018-10-18 16:04 ` David Howells
2018-10-18 16:04 ` David Howells
2018-10-18 20:21 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sh13ya8m.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=adilger@dilger.ca \
--cc=dhowells@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mtk.manpages@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.