[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <191D94B6-B91B-45C0-81A2-C6E7A3124731@dilger.ca>
Date: Fri, 19 Oct 2018 23:55:04 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: David Howells <dhowells@...hat.com>,
Miklos Szeredi <mszeredi@...hat.com>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
linux-kernel@...r.kernel.org,
Linux API <linux-api@...r.kernel.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Florian Weimer <fw@...eb.enyo.de>,
Amir Goldstein <amir73il@...il.com>
Subject: Re: [PATCH v2 6/5] statx: add STATX_RESULT_MASK flag
On Oct 19, 2018, at 11:42 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
>>> +#define STATX_RESULT_MASK STATX__RESERVED
>>
>> Please don't use that bit.
>
> Using it internally is perfectly harmless. If we'll need to extend
> statx in the future and make use of this flag externally, then we can
> easily move the internal flag somewhere else (e.g. extend request_mask
> to 64bit, which we'll probably need to do anyway in that case).
I was thinking about this - what is the point of returning an error
if STATX__RESERVED is set? If this is used to indicate the presence
of e.g. stx_mask2, then newer applications trying to request any of the
flags encoded into stx_mask2 will get an error, rather than the expected
behaviour of "ignore flags you don't understand, and don't set them in
the return stx_mask".
Essentially, this will make STATX__RESERVED useless in the future, since
no application will be able to use it without getting an error if they
are running on an old kernel.
Cheers, Andreas
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
Powered by blists - more mailing lists