Re: [PATCH 01/10] netfilter: x_tables: Merge xt_DSCP.h to xt_dscp.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx wrote:

From: Benjamin Szőke <egyszeregy@xxxxxxxxxxx>

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





[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux