From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:39930 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727395AbeJRPks (ORCPT ); Thu, 18 Oct 2018 11:40:48 -0400 Date: Thu, 18 Oct 2018 09:41:01 +0200 From: Jan Kara To: Amir Goldstein Cc: Miklos Szeredi , Andreas Dilger , "Michael Kerrisk (man-pages)" , David Howells , linux-fsdevel , linux-kernel , linux-api@vger.kernel.org, Jan Kara Subject: Re: statx(2) API and documentation Message-ID: <20181018074101.GJ23493@quack2.suse.cz> References: <006890C4-64D4-4DE2-A1F0-335FFFD585BB@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu 18-10-18 01:15:13, Amir Goldstein wrote: > On Wed, Oct 17, 2018 at 10:12 PM Miklos Szeredi wrote: > > > >> - STATX_ALL definition is unclear, can this change, or is it fixed? > > >> If it's the former, than that's a backward compatibility nightmare. > > >> If it's the latter, then what's the point? > > > > > > The value can change over time. It is intended to reflect the current > > > state of affairs at the time the userspace program and kernel are compiled. > > > The value sent from userspace lets the kernel know what fields are in > > > the userspace struct, so it doesn't try to set fields that aren't there. > > > > What's the point of a userspace program specifying STATX_ALL? Without > > a way to programmatically query the interface definition it's useless: > > there's no way to guess which mask bit corresponds to which field, and > > what that field represents. > > > > And there will be programs out there which specify STATX_ALL without > > considering that in the future it may become slower as it is now due > > to a recompile. > > > > So what's the point exactly? > > > > > The value in the kernel allows masking off new fields from userspace that > > > it doesn't understand. > > > > Okay, but that has nothing to do with the UAPI. Even as an internal > > flag we should be careful, as it might grow uses which can have > > similar issues as the userspace one above. > > > > FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to > add new flags and did not want to change the UAPI _ALL_ constants. > This is how we plan to solve it: > https://github.com/amir73il/linux/commit/8c2b1acadb88ee4505ccc8bfdc665863111fb4cc Yeah, after fanotify experience I find foo_ALL constants useless if not dangerous for userspace. Kernel internal constants like this are IMO useful. Honza -- Jan Kara SUSE Labs, CR