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 X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA379C433E0 for ; Sun, 14 Jun 2020 23:34:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A0EC206D7 for ; Sun, 14 Jun 2020 23:34:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728042AbgFNXem (ORCPT ); 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: ++ 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. >