Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1610613imm; Thu, 18 Oct 2018 00:51:59 -0700 (PDT) X-Google-Smtp-Source: ACcGV63sEjPZdp9S4rZJRr1/WtfVOcVxapGkJgwgV0MWy/QAIM5r1D/EZ7NzkAsaFQFBDthJVXFK X-Received: by 2002:a63:9742:: with SMTP id d2-v6mr27674568pgo.278.1539849119585; Thu, 18 Oct 2018 00:51:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539849119; cv=none; d=google.com; s=arc-20160816; b=K2YyD11tnJ4NMnDNUOimSbuRMbZZEMZ/6sOav2LX6ummFjn2JgL/fVJ7hgPa5nU4Di n5gmkK+rJjkMXUTnzWIvXTZb0WFfpELM4U3PAvwYQHVTc9S7mut6bXw+qMhi1x9jpMPW iHDed1vrGxPYoWupRGRg29/Xx7aewQKhu4Lm2h28v1Ymz3T5IuI/CwNV2zycTKkPZUxU TcwcPvPS+TNeC2M2vyA+KnEy9Jw/hD38/+U8CBtfERSDQQkhE6NmIwmI6ugn5IXfpjCl vE8lb8z5GONXGO1F5VafRtOkalBwigafD7xNLnkuQk4VLlXMgdnmOiVvsnUez/WP2eHt zR2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to:date :references:subject:cc:to:from; bh=XXLtGMcJpslmDlwyElKSTXTqVXKc4s9Avgij8q7YBOY=; b=B3uSTc5fx0U6VT1E+lVIAQ7XjoY6FUKPcbtwrbondH62oVcLvhhn9KbFBmPppduhtW bVX354MmApFoZPPZqIOc7U0+PcYSAcZIHhjBTeEdvX0MjOPA/6j2jUa37bJ99fmMTPPR 8moOPedtp+AO8LZ7y98MnAxVj1AyX5S9M084/PizvXapHL0Fn1YpawEMXwcZZnm/FaxQ PnbCvzNHG9g5t40Ff6uTwWBreXPq/Sxep9f3glCf52JAWrvXIXesMgxNqli6O7/iSHbj XbX4v4WwMHDWcvlaXmb8bQZvsHJUCOB98B+LxPdTXXBqnsv/4dgbUxAlcWKqsYuEi1np aNUg== 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 l9-v6si192749pgj.210.2018.10.18.00.51.43; Thu, 18 Oct 2018 00:51:59 -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 S1727650AbeJRPtT (ORCPT + 99 others); Thu, 18 Oct 2018 11:49:19 -0400 Received: from albireo.enyo.de ([5.158.152.32]:52094 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726031AbeJRPtS (ORCPT ); Thu, 18 Oct 2018 11:49:18 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gD33h-0001Sy-1T; Thu, 18 Oct 2018 07:49:29 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1gD33g-0004FU-T1; Thu, 18 Oct 2018 09:49:28 +0200 From: Florian Weimer To: Jan Kara Cc: Amir Goldstein , Miklos Szeredi , Andreas Dilger , "Michael Kerrisk \(man-pages\)" , David Howells , linux-fsdevel , linux-kernel , linux-api@vger.kernel.org Subject: Re: statx(2) API and documentation References: <006890C4-64D4-4DE2-A1F0-335FFFD585BB@dilger.ca> <20181018074101.GJ23493@quack2.suse.cz> Date: Thu, 18 Oct 2018 09:49:28 +0200 In-Reply-To: <20181018074101.GJ23493@quack2.suse.cz> (Jan Kara's message of "Thu, 18 Oct 2018 09:41:01 +0200") Message-ID: <87in1zy9rr.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jan Kara: > On Thu 18-10-18 01:15:13, Amir Goldstein wrote: >> 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. There are also various *_MAX constants which are increased regularly. Some of them are part of the UAPI headers (INET_DIAG_MAX appears to be a relevant example), some are no longer in UAPI, but still in custom glibc headers (AF_MAX/PF_MAX). These appear to be equally useless.