[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sh13ya8m.fsf@mid.deneb.enyo.de>
Date: Thu, 18 Oct 2018 09:39:21 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Andreas Dilger <adilger@...ger.ca>,
Michael Kerrisk <mtk.manpages@...il.com>,
David Howells <dhowells@...hat.com>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: statx(2) API and documentation
* Miklos Szeredi:
> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer <fw@...eb.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.
Powered by blists - more mailing lists