Re: [PATCH 14/20] x86/barrier: Use alternative_io() in 32-bit barrier functions
From: Ingo Molnar
Date: Sat Mar 15 2025 - 04:52:38 EST
* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 14 Mar 2025 at 11:42, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> >
> > +#define mb() alternative_io("lock addl $0,-4(%%esp)", \
> > + "mfence", X86_FEATURE_XMM2, \
> > + ARG(), \
> > + ARG(), \
> > + ARG("memory", "cc"))
>
> So all of these patches look like good cleanups to me, but I do wonder
> if we should
>
> (a) not use some naming *quite* as generic as 'ARG()'
>
> (b) make the asms use ARG_OUT/ARG_IN/ARG_CLOBBER() to clarify
>
> because that ARG(), ARG(), ARGC() pattern looks odd to me.
>
> Maybe it's just me.
Not just you, and I think the ARG_ prefix still looks a bit too
generic-C to me, it should be something more specific and unambiguously
asm() related, like:
ASM_ARGS_IN(),
ASM_ARGS_OUT(),
ASM_ARGS_CLOBBER(),
or maybe even:
ASM_CONSTRAINT_IN(),
ASM_CONSTRAINT_OUT(),
ASM_CONSTRAINT_CLOBBER(),
Because these asm()-ish syntactic constructs look better in separate
lines anyway, and it's not like we are at risk of running out of
letters in the kernel anytime soon.
Thanks,
Ingo