lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 15 Jun 2020 01:34:33 +0200
From:   "Alexander A. Klimov" <>
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 <>,,,,,,
        Linus Torvalds <>
Subject: Re: Good idea to rename files in include/uapi/ ?

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 

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.

Powered by blists - more mailing lists