Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1603741imm; Thu, 18 Oct 2018 00:42:33 -0700 (PDT) X-Google-Smtp-Source: ACcGV60z/YWEP15euzjWSvJk67ZzBwfvkme2MLuw5/2Z+tzND+zxO3jaP37EwMeI8QimQ1WNkyVX X-Received: by 2002:a63:34c7:: with SMTP id b190-v6mr26785914pga.184.1539848553180; Thu, 18 Oct 2018 00:42:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539848553; cv=none; d=google.com; s=arc-20160816; b=sGhyMipqRkEdoUPY+BD43yHdkdhxBwQaQRq6g4CF915u/V7Tfyf09XL+YpkCUHdVwz hmxmkrfk/I6I9wVnJ0K+7DFWaipRaOh3AxeW3ciSIRS3VwqVlS547ySOU6GzMPejxMK5 LttpR7sTXNvKi0gwK+1OGYsY4fvY243sxhiXMqJm7sXMyQWRfzoqEEphCitJ4p/WwJIN 1Tfp7w8mS+Lw5hCvm5NUQirlMmu0piBfJlBzgHzU/mwaO0EjqyZ5bUaWuDutuPGr+PCO YOUe/7AJYC9rR5yOmTOYJm+NmWul72qBLbCM+PEcOfVTw9w4a2RT9Gt4vIQLp1zu/MCs ZbBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=bo4VXgeV48OszWWE2pXwRhwmg1/DrMSe2ZTDBePL+es=; b=dtyHVLTmhB94XOGGccaU3G5Bjs6xACIe50RjEUqXwf862E7B2s89C4KVzcTrTh2O/0 ArktKHY8k7rtoctLjVprvrpdLo7IT+YpPmTfZTjRjf41JFf73RA5jjF63qpxZUSNzSpV r99TxvaUUQU62B1XFE8xHn5L8grtjqi7/iuioW5C8nfIZXtvw1iMDHQhQXPp/DgOrGQR 0lbBZmI2CFVCYT1J3GFPjBDchyh7Am/fE9ggKZB2pTLDHZVRacIGLeHKrTd6yR5bfjIi IQDI7LyV3ohbTt1DIM+3PAKsmOHpuBZXNQ4mu27DnE4fA60u/UTQ7UdnMeTO+NUJ+Qnj AYig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b27-v6si21076837pgb.156.2018.10.18.00.42.17; Thu, 18 Oct 2018 00:42:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727673AbeJRPks (ORCPT + 99 others); Thu, 18 Oct 2018 11:40:48 -0400 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 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 27D23B047; Thu, 18 Oct 2018 07:41:04 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 9C77B1E088D; Thu, 18 Oct 2018 09:41:01 +0200 (CEST) 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: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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