[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj_F4_uTMQ2w7M7TRJqn9dx+LEifuvkvqd_ODSbMU-U3g@mail.gmail.com>
Date: Fri, 14 Mar 2025 14:16:51 -1000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...nel.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, 14 Mar 2025 at 14:09, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> 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.
.. but I think it does so very badly because "io" really means
something else entirely in absolutely all other contexts.
And it really makes no sense as "io", since it doesn't take inputs and
outputs, it takes inputs, outputs AND CLOBBERS.
So it would make more sense to call it "ioc", but that's just obvious
nonsense, and "ioc" is already taken as a globally recognized
shorthand for "corruption in sports".
So "ioc" is bad too, but that should make you go "Oh, 'io' is _doubly_
nonsensical".
Ergo: I think "asm" would be a better distinguishing marker, withg the
plain "alternative()" being used for particularly simple asms.
Linus
Powered by blists - more mailing lists