From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: undef REG_IN/REG_OUT to avoid define collisions
Date: Thu, 31 Mar 2022 00:32:41 +0200 [thread overview]
Message-ID: <8735iznkae.ffs@tglx> (raw)
In-Reply-To: <YkR9TD4+9LzH1N6b@smile.fi.intel.com>
On Wed, Mar 30 2022 at 18:54, Andy Shevchenko wrote:
> On Wed, Mar 30, 2022 at 08:33:26AM -0700, Dave Hansen wrote:
>> On 3/30/22 08:28, Neil Armstrong wrote:
>> > diff --git a/arch/x86/include/asm/arch_hweight.h b/arch/x86/include/asm/arch_hweight.h
>> > index ba88edd0d58b..139a4b0a2a14 100644
>> > --- a/arch/x86/include/asm/arch_hweight.h
>> > +++ b/arch/x86/include/asm/arch_hweight.h
>> > @@ -52,4 +52,7 @@ static __always_inline unsigned long __arch_hweight64(__u64 w)
>> > }
>> > #endif /* CONFIG_X86_32 */
>> >
>> > +#undef REG_IN
>> > +#undef REG_OUT
>>
>> Wouldn't it be a bit less hackish to give these a more qualified name
>> like HWEIGHT_REG_IN?
Absolutely.
> Either way, would it be good to undef them here anyway?
No. Unconditional #undef is a guarantee for hard to diagnose trouble
because it papers over namespace collisions. You can end up with the
wrong constants in your binary which might work well except for the once
in the blue moon corner case.
Been there and stared at such nonsense for weeks...
Name spaces exist for a reason and we are not short of characters here.
Thanks,
tglx
prev parent reply other threads:[~2022-03-30 22:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 15:28 [PATCH] x86: undef REG_IN/REG_OUT to avoid define collisions Neil Armstrong
2022-03-30 15:33 ` Dave Hansen
2022-03-30 15:54 ` Andy Shevchenko
2022-03-30 22:32 ` Thomas Gleixner [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=8735iznkae.ffs@tglx \
--to=tglx@linutronix.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=narmstrong@baylibre.com \
--cc=x86@kernel.org \
/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