[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <E2531F1C-94F9-4E65-9375-DD19C16C7DD7@zytor.com>
Date: Sun, 16 Mar 2025 11:34:38 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>
CC: Uros Bizjak <ubizjak@...il.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH] x86/asm: Use alternative_input() in amd_clear_divider()
On March 15, 2025 2:36:55 PM PDT, Borislav Petkov <bp@...en8.de> wrote:
>On Sat, Mar 15, 2025 at 10:29:25PM +0100, Ingo Molnar wrote:
>> So why does the higher level alternative_input() API exist? If it
>> shouldn't exist then we should remove it. If it exists, we should use
>> it consistently instead of open-coding its equivalent.
>>
>> Cleanups like this, especially if they are clearly part of an effort to
>> improve x86 code generation in this area, are not 'code churn', why
>> would they be?
>
>Because this is not improving anything, IMO. It is simply writing it
>differently, perhaps obscuring it more in the process.
>
>And I, just like hpa, would need to go look at alternative_input() to figure
>out what really happens there.
>
>Dunno, maybe we should really remove alternative_input() instead...
>
My main beef with the "higher level" macros is that they both obscure what is going on and they have a syntax which is very different from the typical asm statement, all of which makes them harder to read. Furthermore, they don't cover all the possible ways that one can use the alternatives API – and because cpp doesn't lend itself well to handling the colon-separated groups of asm syntax – that really can't be fixed easily.
Powered by blists - more mailing lists