Good idea to rename files in include/uapi/ ?

Good idea to rename files in include/uapi/ ?

[Alexander A. Klimov]

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

Re: Good idea to rename files in include/uapi/ ?

[David Howells]

Alexander A. Klimov <grandmaster@al2klimov.de> 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

Re: Good idea to rename files in include/uapi/ ?

[Stefano Brivio]

On Sun, 14 Jun 2020 21:41:17 +0200
"Alexander A. Klimov" <grandmaster@al2klimov.de> 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

Re: Good idea to rename files in include/uapi/ ?

[Jan Engelhardt]

On Sunday 2020-06-14 22:19, David Howells wrote:
>Alexander A. Klimov <grandmaster@al2klimov.de> 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.

Re: Good idea to rename files in include/uapi/ ?

[Pablo Neira Ayuso]

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 <grandmaster@al2klimov.de> 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.

Re: Good idea to rename files in include/uapi/ ?

[Al Viro]

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.

Re: Good idea to rename files in include/uapi/ ?

[Alexander A. Klimov]

Am 14.06.20 um 22:34 schrieb Stefano Brivio:
> On Sun, 14 Jun 2020 21:41:17 +0200
> "Alexander A. Klimov" <grandmaster@al2klimov.de> 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.

> 

Re: Good idea to rename files in include/uapi/ ?

[Alexander A. Klimov]

Am 14.06.20 um 23:08 schrieb Jan Engelhardt:
> 
> On Sunday 2020-06-14 22:19, David Howells wrote:
>> Alexander A. Klimov <grandmaster@al2klimov.de> 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.
> 

Re: Good idea to rename files in include/uapi/ ?

[Geert Uytterhoeven]

Hi Alexander,

On Mon, Jun 15, 2020 at 1:11 AM Alexander A. Klimov
<grandmaster@al2klimov.de> 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 -- geert@linux-m68k.org

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

Re: Good idea to rename files in include/uapi/ ?

[Geert Uytterhoeven]

Hi Alexander,

On Sun, Jun 14, 2020 at 9:44 PM Alexander A. Klimov
<grandmaster@al2klimov.de> 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 -- geert@linux-m68k.org

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

Re: Good idea to rename files in include/uapi/ ?

[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 .

Re: Good idea to rename files in include/uapi/ ?

[Pablo Neira Ayuso]

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 ?

Re: Good idea to rename files in include/uapi/ ?

[Alexander A. Klimov]

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.