linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: xianfengting221@163.com
Cc: leon@kernel.org, saeedm@mellanox.com, kuba@kernel.org,
	netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/mlx5: Add a missing macro undefinition
Date: Sun, 07 Jun 2020 16:36:48 -0700 (PDT)	[thread overview]
Message-ID: <20200607.163648.1680419872557863264.davem@davemloft.net> (raw)
In-Reply-To: <c96f7991-3858-4351-9804-4482e7689cd7@163.com>

From: Hu Haowen <xianfengting221@163.com>
Date: Sun, 7 Jun 2020 14:55:33 +0800

> 
> On 2020/6/7 2:36 PM, Leon Romanovsky wrote:
>> On Sun, Jun 07, 2020 at 01:12:40PM +0800, Hu Haowen wrote:
>>> The macro ODP_CAP_SET_MAX is only used in function
>>> handle_hca_cap_odp()
>>> in file main.c, so it should be undefined when there are no more uses
>>> of it.
>>>
>>> Signed-off-by: Hu Haowen <xianfengting221@163.com>
>>> ---
>>>   drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>> "should be undefined" is s little bit over statement, but overall
>> the patch is good.
> 
> 
> Sorry for my strong tone, but my idea is that every macro which is
> defined and used just in a single function, is supposed to be
> undefined
> at the end of its final use, so that you won't get into trouble next
> time if you define a macro with the same name as this one.

The compiler would generate an error if that happened, so you would
not get into "trouble".

I fail to see the value in this change at all, sorry.

Really, what's the point?

Does it make the code harder to read?  No.

Does it cause problems if you accidently want to use that macro name
again in the same compilation unit?  No.

So I have yet to hear a valid "why" to make this kind of change and
I'd like to stop this set of cleanups before it gets out of control
and we have these ugly #undef statements all over the tree.

Thank you.

      reply	other threads:[~2020-06-07 23:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-07  5:12 [PATCH] net/mlx5: Add a missing macro undefinition Hu Haowen
2020-06-07  6:36 ` Leon Romanovsky
2020-06-07  6:55   ` Hu Haowen
2020-06-07 23:36     ` David Miller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200607.163648.1680419872557863264.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=xianfengting221@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).