Hello there!
At the moment one can't checkout a clean working directory w/o any
changed files on a case-insensitive FS as the following file names have
lower-case duplicates:
➜ linux git:(96144c58abe7) git ls-files |sort -f |uniq -id
include/uapi/linux/netfilter/xt_CONNMARK.h
include/uapi/linux/netfilter/xt_DSCP.h
include/uapi/linux/netfilter/xt_MARK.h
include/uapi/linux/netfilter/xt_RATEEST.h
include/uapi/linux/netfilter/xt_TCPMSS.h
include/uapi/linux/netfilter_ipv4/ipt_ECN.h
include/uapi/linux/netfilter_ipv4/ipt_TTL.h
include/uapi/linux/netfilter_ipv6/ip6t_HL.h
net/netfilter/xt_DSCP.c
net/netfilter/xt_HL.c
net/netfilter/xt_RATEEST.c
net/netfilter/xt_TCPMSS.c
tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus
➜ linux git:(96144c58abe7)
Also even on a case-sensitive one VIm seems to have trouble with editing
both case-insensitively equal files at the same time.
I was going to make a patch renaming the respective duplicates, but I'm
not sure:
*Is it a good idea to rename files in include/uapi/ ?*
Best,
AK
Alexander A. Klimov <[email protected]> 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.
David
On Sun, 14 Jun 2020 21:41:17 +0200
"Alexander A. Klimov" <[email protected]> wrote:
> Hello there!
>
> At the moment one can't checkout a clean working directory w/o any
> changed files on a case-insensitive FS as the following file names have
> lower-case duplicates:
They are not duplicates: matching extensions are lowercase, target
extensions are uppercase. DSCP is the extension to set DSCP bits, dscp
is the extension to match on those packet bits.
> ➜ linux git:(96144c58abe7) git ls-files |sort -f |uniq -id
> include/uapi/linux/netfilter/xt_CONNMARK.h
> include/uapi/linux/netfilter/xt_DSCP.h
> include/uapi/linux/netfilter/xt_MARK.h
> include/uapi/linux/netfilter/xt_RATEEST.h
> include/uapi/linux/netfilter/xt_TCPMSS.h
> include/uapi/linux/netfilter_ipv4/ipt_ECN.h
> include/uapi/linux/netfilter_ipv4/ipt_TTL.h
> include/uapi/linux/netfilter_ipv6/ip6t_HL.h
> net/netfilter/xt_DSCP.c
> net/netfilter/xt_HL.c
> net/netfilter/xt_RATEEST.c
> net/netfilter/xt_TCPMSS.c
> tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus
> ➜ linux git:(96144c58abe7)
>
> Also even on a case-sensitive one VIm seems to have trouble with editing
> both case-insensitively equal files at the same time.
...what trouble exactly?
> I was going to make a patch renaming the respective duplicates, but I'm
> not sure:
>
> *Is it a good idea to rename files in include/uapi/ ?*
I'm not sure it's a good idea to even use git on a case-insensitive
filesystem. I'm curious, what is your use case?
--
Stefano
On Sunday 2020-06-14 22:19, David Howells wrote:
>Alexander A. Klimov <[email protected]> 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
big deal either.
A header file rename is no problem. We even have dummy headers
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.
On Sun, Jun 14, 2020 at 11:08:08PM +0200, Jan Engelhardt wrote:
>
> On Sunday 2020-06-14 22:19, David Howells wrote:
> >Alexander A. Klimov <[email protected]> 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.
That's only because NFLOG has been there for ~10 years, so it was safe
to remove ULOG support.
On Sun, Jun 14, 2020 at 09:41:17PM +0200, Alexander A. Klimov wrote:
> Hello there!
>
> At the moment one can't checkout a clean working directory w/o any changed
> files on a case-insensitive FS as the following file names have lower-case
> duplicates:
And if you use a filesystem that is limited to 14 characters in name (or that
weird 8 + 3 thing) you'll also have problems. Doctor, it hurts when I do it...
> Also even on a case-sensitive one VIm seems to have trouble with editing
> both case-insensitively equal files at the same time.
So file a bug report against vim. Or use a vi variant without such a problem
(FWIW, nvi has nothing of that sort).
> I was going to make a patch renaming the respective duplicates, but I'm not
> sure:
>
> *Is it a good idea to rename files in include/uapi/ ?*
It is not. Strictly speaking, C99 allows implementation to consider the
header names differing only in case as refering to the same file, but then
it allows to ignore everything between the 8th character and the first
dot in those. Not done on Unices, so #include <Shite.h> is not going to
pick /usr/include/shite.h
If it's used by any userland code, that's it - changing the name (in any fashion)
will break that userland code. If it isn't, it shouldn't have been in include/uabi
in the first place.
Am 14.06.20 um 22:34 schrieb Stefano Brivio:
> On Sun, 14 Jun 2020 21:41:17 +0200
> "Alexander A. Klimov" <[email protected]> wrote:
>
>> Hello there!
>>
>> At the moment one can't checkout a clean working directory w/o any
>> changed files on a case-insensitive FS as the following file names have
>> lower-case duplicates:
>
> They are not duplicates: matching extensions are lowercase, target
> extensions are uppercase. DSCP is the extension to set DSCP bits, dscp
> is the extension to match on those packet bits.
>
>> ➜ linux git:(96144c58abe7) git ls-files |sort -f |uniq -id
>> include/uapi/linux/netfilter/xt_CONNMARK.h
>> include/uapi/linux/netfilter/xt_DSCP.h
>> include/uapi/linux/netfilter/xt_MARK.h
>> include/uapi/linux/netfilter/xt_RATEEST.h
>> include/uapi/linux/netfilter/xt_TCPMSS.h
>> include/uapi/linux/netfilter_ipv4/ipt_ECN.h
>> include/uapi/linux/netfilter_ipv4/ipt_TTL.h
>> include/uapi/linux/netfilter_ipv6/ip6t_HL.h
>> net/netfilter/xt_DSCP.c
>> net/netfilter/xt_HL.c
>> net/netfilter/xt_RATEEST.c
>> net/netfilter/xt_TCPMSS.c
>> tools/memory-model/litmus-tests/Z6.0+pooncelock+poonceLock+pombonce.litmus
>> ➜ linux git:(96144c58abe7)
>>
>> Also even on a case-sensitive one VIm seems to have trouble with editing
>> both case-insensitively equal files at the same time.
>
> ...what trouble exactly?
vi -O2 include/uapi/linux/netfilter/xt_CONNMARK.h
include/uapi/linux/netfilter/xt_connmark.h
... opens the first file two times.
>
>> I was going to make a patch renaming the respective duplicates, but I'm
>> not sure:
>>
>> *Is it a good idea to rename files in include/uapi/ ?*
>
> I'm not sure it's a good idea to even use git on a case-insensitive
> filesystem. I'm curious, what is your use case?
My MacOS workstation. Now as I discovered the problem I've created a r/w
image with a c/s FS, but the need of that for a clean `git checkout .'
is IMAO pretty silly.
Don't worry, I run Linux, but only on my servers.
Also this issue should also apply to M$ Windows workstations. By the way
at work I actually use Git on Windows if needed and it also just works.
However the software I work on doesn't have this issue.
>
Am 14.06.20 um 23:08 schrieb Jan Engelhardt:
>
> On Sunday 2020-06-14 22:19, David Howells wrote:
>> Alexander A. Klimov <[email protected]> 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.
>
Hi Alexander,
On Mon, Jun 15, 2020 at 1:11 AM Alexander A. Klimov
<[email protected]> wrote:
> Am 14.06.20 um 22:34 schrieb Stefano Brivio:
> > On Sun, 14 Jun 2020 21:41:17 +0200
> >> Also even on a case-sensitive one VIm seems to have trouble with editing
> >> both case-insensitively equal files at the same time.
> >
> > ...what trouble exactly?
> vi -O2 include/uapi/linux/netfilter/xt_CONNMARK.h
> include/uapi/linux/netfilter/xt_connmark.h
>
> ... opens the first file two times.
Works fine for me, using vim 2:8.0.1453-1ubuntu1.3.
You must be using a buggy version.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Alexander,
On Sun, Jun 14, 2020 at 9:44 PM Alexander A. Klimov
<[email protected]> wrote:
> *Is it a good idea to rename files in include/uapi/ ?*
No it is not: include/uapi/ is append-only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Monday 2020-06-15 01:34, Alexander A. Klimov wrote:
>>
>> 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?
I had already given the commit with the (email) message:
>> Just look at xt_MARK.h, all it does is include xt_mark.h. Cf.
>> 28b949885f80efb87d7cebdcf879c99db12c37bd .
On Mon, Jun 22, 2020 at 01:37:09PM +0200, Jan Engelhardt wrote:
>
> On Monday 2020-06-15 01:34, Alexander A. Klimov wrote:
> >>
> >> 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?
>
> I had already given the commit with the (email) message:
>
> >> Just look at xt_MARK.h, all it does is include xt_mark.h. Cf.
> >> 28b949885f80efb87d7cebdcf879c99db12c37bd .
Why rename this in 2020 ?
Am 22.06.20 um 13:37 schrieb Jan Engelhardt:
>
> On Monday 2020-06-15 01:34, Alexander A. Klimov wrote:
>>>
>>> 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?
>
> I had already given the commit with the (email) message:
>
>>> Just look at xt_MARK.h, all it does is include xt_mark.h. Cf.
>>> 28b949885f80efb87d7cebdcf879c99db12c37bd .
In that commit no .h file disappeared.