Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1262435ybt; Sun, 14 Jun 2020 16:36:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzCyUVxkhNpddQBLe+u191uZzq4TZUyZW9PU8ZLPSfTz1v6x4qI3QYn6pXZ6iwq/0l8SxbB X-Received: by 2002:a05:6402:cbc:: with SMTP id cn28mr22036781edb.220.1592177806823; Sun, 14 Jun 2020 16:36:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592177806; cv=none; d=google.com; s=arc-20160816; b=F60s0rJyc5yNjThSPdbGdsJ5/624QgvADAB6gOi2jJjgkLfRoKSliQVm852yl+B7EC Jyg1W7jMLSCloSc15MraWPdHCtkBBjk/FUErZjqzmC6jPRCZu8r3MhfqRI0Rbt4nISuD Lxo2oXChR6PFukLmA3jr2nltjC96Klb9ThfE63DfRCFBQ3mKF79AhX0ZemT7fLMmJsaV YSPIHC8J9XoPng18/l2cPSRViIYnfQ+k1A1dIugff386jrpLEKcJPNHgpu27/jfqdDSi Er7E6WTL/SNp+PikwTujQEneaGMcPGeuXLYjI4xx48K89JMquty+OUSMMIqgJjMcwreK +nQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:date:message-id:from :references:cc:to:subject; bh=GzSzFCMz93l0P4K8gpoUGnX5frTIpvIv03DidN+C2Xc=; b=lR3uzU8dq5jyPEncnWpgD+h0ND/Kk28ckbguwB/3hwwwtJ5k/tJKP1E+0dsDxyp8kG 5rSwGMASbunqfo9OiCgbBGUqpAyWjYKUpssGzimhRAgf33ERlR4F5zfG5Dmi9U6jNEei 53hEWPoPtS0XybrL5DbjQnibjf85S70kzmwnZjmTRIknv+fQpDEsaC6Mq9AT24iOWq5L kPOv/rsVQE2Y8/sCL8a2IreftyH+GbISTzP22EM7G3voPm+ngpY2KbrIWgZuU5ZDxewF wTKtM5Hvc2isvovmbgmXlmqKbM9snQ1zgcsXEagJxNziVCHgTtxta91GZGwv87SEPfvH P9GA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r16si8327109eds.6.2020.06.14.16.36.25; Sun, 14 Jun 2020 16:36:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728038AbgFNXem (ORCPT + 99 others); Sun, 14 Jun 2020 19:34:42 -0400 Received: from smtp.al2klimov.de ([78.46.175.9]:60206 "EHLO smtp.al2klimov.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727928AbgFNXel (ORCPT ); Sun, 14 Jun 2020 19:34:41 -0400 X-Greylist: delayed 13996 seconds by postgrey-1.27 at vger.kernel.org; Sun, 14 Jun 2020 19:34:40 EDT Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by smtp.al2klimov.de (Postfix) with ESMTPA id D5E8B1B599B; Sun, 14 Jun 2020 23:34:34 +0000 (UTC) Subject: Re: Good idea to rename files in include/uapi/ ? To: Jan Engelhardt , David Howells Cc: Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , "David S. Miller" , Jakub Kicinski , Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-arch@vger.kernel.org, Linus Torvalds References: <9feded75-4b45-2821-287b-af00ec5f910f@al2klimov.de> <174102.1592165965@warthog.procyon.org.uk> From: "Alexander A. Klimov" Message-ID: Date: Mon, 15 Jun 2020 01:34:33 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spamd-Bar: ++ X-Spam-Level: ** Authentication-Results: smtp.al2klimov.de; auth=pass smtp.auth=aklimov@al2klimov.de smtp.mailfrom=grandmaster@al2klimov.de Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 14.06.20 um 23:08 schrieb Jan Engelhardt: > > On Sunday 2020-06-14 22:19, David Howells wrote: >> Alexander A. Klimov wrote: >> >>> *Is it a good idea to rename files in include/uapi/ ?* >> >> Very likely not. If programs out there are going to be built on a >> case-sensitive filesystem (which happens all the time), they're going to break >> if you rename the headers. We're kind of stuck with them. > > Netfilter has precedent for removing old headers, e.g. > 7200135bc1e61f1437dc326ae2ef2f310c50b4eb's ipt_ULOG.h. > > Even if kernels would not remove such headers, the iptables userspace > code wants to be buildable with all kinds of kernels, including past > releases, which do not have modern headers like xt_l2tp.h. > > The mantra for userspace programs is therefore "copy the headers" — > because you never know what /usr/include/linux you get. iptables and > iproute2 are two example codebases that employ this. And when headers > do get copied, header removals from the kernel side are no longer a Absolutely correct, "*when* headers do get copied ..." > big deal either. > > A header file rename is no problem. We even have dummy headers Hmm.. if I understand all of you correctly, David, Stefano, Pablo and Al say like no, not a good idea, but only you, Jan, say like should be no problem. Jan, do you have anything like commit messages in mainline or public emails from maintainers confirming your opinion? What exactly makes you sure that Torvalds, the #1 protector of the userspace, would tolerate a such patch from me? Yes, it would break the A*P*I, and not the A*B*I, but who knows.. > already because of this... or related changes. Just look at > xt_MARK.h, all it does is include xt_mark.h. Cf. > 28b949885f80efb87d7cebdcf879c99db12c37bd . > > The boilerplate for xt_*h is quite high thanks to the miniscule > splitting of headers. Does not feel right in this day and age. >