From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D2190C433EF for ; Wed, 12 Jan 2022 08:29:21 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4JYghc2vrvz3bc5 for ; Wed, 12 Jan 2022 19:29:20 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.126.134; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4JYgh23QH6z2xBx for ; Wed, 12 Jan 2022 19:28:48 +1100 (AEDT) Received: from mail-wr1-f43.google.com ([209.85.221.43]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MBll6-1nD6tU0npE-00C8RD for ; Wed, 12 Jan 2022 09:28:44 +0100 Received: by mail-wr1-f43.google.com with SMTP id x4so2721061wru.7 for ; Wed, 12 Jan 2022 00:28:43 -0800 (PST) X-Gm-Message-State: AOAM530yFbjH2uADvXzALMZOyuCNZeGUMIaH0T1TT6BBvpjjO4/LXPIO Wduu5qiDLyNJJAR7wxAnF1TkmGkysSwR900gsh0= X-Google-Smtp-Source: ABdhPJzCQAXjKL7v7gwqeNOizFH7EmO4xK5MJG/Z0khXPuJErSXk+hZMQMifsbbqaAU9IP9YduLhizzW87q9+u/zsmI= X-Received: by 2002:a05:6000:16c7:: with SMTP id h7mr6863134wrf.317.1641976123587; Wed, 12 Jan 2022 00:28:43 -0800 (PST) MIME-Version: 1.0 References: <20220111083515.502308-1-hch@lst.de> <20220111083515.502308-5-hch@lst.de> <20220112075609.GA4854@lst.de> In-Reply-To: <20220112075609.GA4854@lst.de> From: Arnd Bergmann Date: Wed, 12 Jan 2022 09:28:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h To: Christoph Hellwig Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:VOJqlejMXaRdTb88eG//FZGDoydWp5kkuPsXP8s2oFMZ1a6qp4M njm3yW6J/auNV04skzU0EMO7gBr4ajoCecOHpDPlgVqEHDo+GwYj39j2LSMox6UDYjjk84p MANtA2882HLEZ9GY5e5RAkVu7a+r+71JFin2e8vDc0lzsKWASkrQdL86Bh8biocFr3KaHWn cN3ww15LraJBdX4dDICTg== X-UI-Out-Filterresults: notjunk:1;V03:K0:HjIeWfOe2HU=:Uw9A2AV9dUNMAEBEyz3Xks 8+aDjg+1LLikj0I+/PQoSN/LDfzeXuBKB/7atElrJtiPT2UMjVrDpaBfpf+Ln+xqKi92CxWRw lXMC1e6ga/P6uslI98NR5/AipKwTI/4gItAU+cXtRGi+BUENgsRdU/VFBJcFi4TgTkJVbFkwa Edb0BKIVa35j4kuJ1WtEgUYpxmadip1h1/6QFysQytyAXKsW9Nw3opNf58JTS6wsPjlJ2OSr9 64wTWb6YEKiwVfDZOU27gpa0Vz2g/Hwp7ltzkRcgD3iiKfS5m1w11R2ozhzSvjY2xyaC+nOr0 XqMLlh72ofFhgxat2CQR5ni5dZkIZYNKcrQZzzPDjs61+HvzPRMj6qJre7ZI4S77Du01jLhoL uD01n4hCz8WTtquRJNBq9x8ZytYnSI7ZZp+DzlYXH6AHWzBQNDI1v2MlPNX4q9i8r4V9iOFOt WKkQp7SAtbIXQlSMtpx8e2as2DC1ejrK/Sm1WubqRwMM04yY/GyF6WSKAAAczQ/Pvu5ASw1Ys NN4Bj1duj5sxkEUN0Gw5uvBJj6U10qaJux17jHVfMclSs/xDdRadobMPr1oRxo85Qaj42YGQF 2rG27xMNjUnEskAqtMxOiuwyCC0151h0FWB8XW9p0LFE/oJ/7MP0tetRZ9Zh3mI0xSqs2OE3U 1f0l0KpQKjD8unDiOFTGhz1ZFtPCd7inu3XuYsttANSKOETk46qGmH8lLKlX5JHAeZVM= X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , linux-s390 , Parisc List , Arnd Bergmann , the arch/x86 maintainers , Jeff Layton , "open list:BROADCOM NVRAM DRIVER" , Linux Kernel Mailing List , "J. Bruce Fields" , Guo Ren , sparclinux , linuxppc-dev , Linux ARM Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig wrote: > > On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote: > > This is a very subtle change to the exported UAPI header contents: > > On 64-bit architectures, the three unusable numbers are now always > > shown, rather than depending on a user-controlled symbol. > > Well, the change is bigger and less subtle. Before this change the > constants were never visible to userspace at all (except on mips), > because the #ifdef CONFIG_64BIT it never set for userspace builds. I suppose you mean /always/ visible here, with that ifndef. > > This is probably what we want here for compatibility reasons, but I think > > it should be explained in the changelog text, and I'd like Jeff or Bruce > > to comment on it as well: the alternative here would be to make the > > uapi definition depend on __BITS_PER_LONG==32, which is > > technically the right thing to do but more a of a change. > > I can change this to #if __BITS_PER_LONG==32 || defined(__KERNEL__), > but it will still be change in what userspace sees. Exactly, that is the tradeoff, which is why I'd like the flock maintainers to say which way they prefer. We can either do it more correctly (hiding the constants from user space when they are not usable), or with less change (removing the incorrect #ifdef). Either way sounds reasonable to me, I mainly care that this is explained in the changelog and that the maintainers are aware of the two options. Arnd