[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <jdcd4zoezsi7beoak43dqzkxnel7hqdhtyqbf4cqr6rvs3qfyf@i2qhxrld5p5l>
Date: Fri, 14 Mar 2025 17:09:14 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>,
Uros Bizjak <ubizjak@...il.com>, Andrew Cooper <andrew.cooper3@...rix.com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 14/20] x86/barrier: Use alternative_io() in 32-bit
barrier functions
On Fri, Mar 14, 2025 at 01:54:00PM -1000, Linus Torvalds wrote:
> On Fri, 14 Mar 2025 at 13:49, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > because that ARG(), ARG(), ARGC() pattern looks odd to me.
> >
> > Maybe it's just me.
>
> Oh, and the other thing I reacted to is that I think the
> "alternative_io()" thing should be renamed.
>
> The "io" makes me think "actual I/O". As in PCI or disks or whatever.
> It always read oddly, but now it's *comletely* pointless, because the
> new macro model actually takes pretty much arbitrary asm arguments, to
> the "both input and output arguments" no longer makes any real sense.
>
> So I think it would be better to just call this "alternative_asm()",
> and make naming simpler. Hmm?
Thing is, we still have alternative(), which is also an asm wrapper, but
it's for when the caller doesn't care about adding any constraints.
So the "_io()" distinguishes from that.
--
Josh
Powered by blists - more mailing lists