[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a42bcc51-255f-4c52-b95c-56e562946d3a@freemail.hu>
Date: Wed, 8 Jan 2025 22:08:17 +0100
From: Szőke Benjamin <egyszeregy@...email.hu>
To: Jozsef Kadlecsik <kadlec@...filter.org>
Cc: Florian Westphal <fw@...len.de>, Pablo Neira Ayuso <pablo@...filter.org>,
lorenzo@...nel.org, daniel@...earbox.net, leitao@...ian.org,
amiculas@...co.com, David Miller <davem@...emloft.net>, dsahern@...nel.org,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 01/10] netfilter: x_tables: Merge xt_DSCP.h to xt_dscp.h
2025. 01. 08. 21:11 keltezéssel, Jozsef Kadlecsik írta:
> On Tue, 7 Jan 2025, Szőke Benjamin wrote:
>
>> 2025. 01. 07. 20:23 keltezéssel, Jozsef Kadlecsik írta:
>>> On Tue, 7 Jan 2025, egyszeregy@...email.hu wrote:
>>>
>>>> From: Benjamin Szőke <egyszeregy@...email.hu>
>>>>
>>>> Merge xt_DSCP.h to xt_dscp.h header file.
>>>
>>> I think it'd be better worded as "Merge xt_DSCP.h into the xt_dscp.h
>>> header file." (and in the other patches as well).
>>
>> There will be no any new patchset refactoring anymore just of some
>> cosmetics change. If you like to change it, feel free to modify it in my
>> pacthfiles before the final merging. You can do it as a maintainer.
>
> We don't modify accepted patches. It rarely happens when time presses and
> even in that case it is discussed publicly: "sorry, no time to wait for
> *you* to respin your patch, so I'm going to fix this part, OK?"
>
> But there's no time constrain here. So it'd be strange at the minimum if
> your submitted patches were modified by a maintainer at merging.
>
> Believe it or not, I'm just trying to help to get your patches into the
> best shape.
>
Holyday session is end, i have no time to refactoring and regenerate my patchset
in every day, because you have a new idea about cosmetics changes in every next
days. (this is why asked you before what you like to get, there was no any answer)
If you feel it is need, you can solve it as a maintainer, i know. If you found
any critical issue i can fix it later, please start to look for them, but i will
not waste my time with this usless commit name and header comment changes,
sorry. It is a hobby, i am not a paied Linux developer which is supported by a
company for this stuff.
As a maintainer you can solve this cosmetics things later in an extra patch or
before the merging, lets do it.
>>>> -#ifndef _XT_DSCP_H
>>>> -#define _XT_DSCP_H
>>>> +#ifndef _UAPI_XT_DSCP_H
>>>> +#define _UAPI_XT_DSCP_H
>>>
>>> In the first four patches you added the _UAPI_ prefix to the header
>>> guards while in the next three ones you kept the original ones. Please
>>> use one style consistently.
>>
>> Style consistently is done in the following files:
>>
>> - All of xt_*.h files in uppercase name format (old headers for "target")
>> - All of xt_*.h files in lowercase name format (merged header files)
>>
>> Originally, in these files there was a chaotic state before, it was a
>> painful for my eyes, this is why they got these changes. In ipt_*.h
>> files the original codes got a far enough consistently style before,
>> they was not changed.
>>
>> In my patchsets, It's not my scope/job to make up for the
>> improvements/refactoring of the last 10 years.
>
> But you are just introducing new inconsistencies:
>
> --- a/include/uapi/linux/netfilter/xt_dscp.h
> +++ b/include/uapi/linux/netfilter/xt_dscp.h
> ...
> -#ifndef _XT_DSCP_H
> -#define _XT_DSCP_H
> +#ifndef _UAPI_XT_DSCP_H
> +#define _UAPI_XT_DSCP_H
>
> however
>
> --- a/include/uapi/linux/netfilter_ipv4/ipt_ecn.h
> +++ b/include/uapi/linux/netfilter_ipv4/ipt_ecn.h
> ...
> #ifndef _IPT_ECN_H
> #define _IPT_ECN_H
>
> Why the "_UAPI_" prefixes are needed in the xt_*.h header files?
>
Because it is in the UAPI region, don't you hear about the namespace? It is not
only relevant for OOP languages.
https://www.educative.io/answers/what-is-a-namespace
Here is a good any nice example which also got _UAPI prefix in Linux kernel
source:
https://github.com/torvalds/linux/blob/master/include/uapi/linux/iio/buffer.h
By the way, in the API folder, all header should have have had a prefix
otherwise it can cause conflict with a same non-uapi header like these:
include/net/netfilter
/xt_rateest.h ->
https://github.com/torvalds/linux/blob/master/include/net/netfilter/xt_rateest.h
include/uapi/linux/netfilter
/xt_rateest.h ->
https://github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/xt_rateest.h
In ipt_*.h, include guards are consistent (where i did any changes) but sure
they should have to got that _UAPI prefix also. But this is not the scpoe in my
patch, to rafectoring the full netfilter part of the UAPI in Linux, sorry.
Please sit down and do it as a maintainer, there were no any relevant
refactoring in the past 10 years in this code parts.
> Best regards,
> Jozsef
Powered by blists - more mailing lists