[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230915074647.GA6721@noisy.programming.kicks-ass.net>
Date: Fri, 15 Sep 2023 09:46:47 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, David.Kaplan@....com,
Andrew.Cooper3@...rix.com, jpoimboe@...nel.org,
gregkh@...uxfoundation.org, nik.borisov@...e.com
Subject: Re: [PATCH v2 10/11] x86/alternatives: Simplify ALTERNATIVE_n()
On Wed, Sep 13, 2023 at 04:38:47PM +0200, Borislav Petkov wrote:
> [ bp: Make labels unique and thus all sizing use unambiguous labels.
> Add more info. ]
> +#define __ALTERNATIVE(oldinstr, newinstr, ft_flags, n) \
> + OLDINSTR(oldinstr, n) \
> + ALTINSTR_ENTRY(ft_flags) \
> + ALTINSTR_REPLACEMENT(newinstr)
> +#define ALTERNATIVE_2(oldinst, newinst1, flag1, newinst2, flag2) \
> + __ALTERNATIVE(ALTERNATIVE(oldinst, newinst1, flag1), \
> + newinst2, flag2, 1)
> +#define ALTERNATIVE_3(oldinst, newinst1, flag1, newinst2, flag2, \
> + newinst3, flag3) \
> + __ALTERNATIVE(ALTERNATIVE_2(oldinst, newinst1, flag1, newinst2, flag2), \
> + newinst3, flag3, 2)
So I see what you did with that @n argument, but urgh, do we really need
this? I mean, it just makes things harder to use and it doesn't actually
fix anything.. :/
Powered by blists - more mailing lists