On 09.04.2024 09:39, Oleksii wrote: > On Mon, 2024-04-08 at 10:23 +0200, Jan Beulich wrote: >> On 03.04.2024 12:20, Oleksii Kurochko wrote: >>> +/* >>> + * Only CONFIG_GENERIC_ATOMIC64=y was ported to Xen that is the >>> reason why >>> + * last argument of ATOMIC_FETCH_OP, ATOMIC_OP_RETURN isn't used. >>> + */ >>> +#define ATOMIC_OPS(op, asm_op, c_op, >>> unary_op) \ >>> + ATOMIC_FETCH_OP( op, asm_op, unary_op, w, int, >>> ) \ >>> + ATOMIC_OP_RETURN(op, asm_op, c_op, unary_op, w, int, ) >>> + >>> +ATOMIC_OPS(add, add, +, +) >>> +ATOMIC_OPS(sub, add, +, -) >>> + >>> +#undef ATOMIC_OPS >>> + >>> +#define ATOMIC_OPS(op, asm_op, unary_op) \ >>> + ATOMIC_FETCH_OP(op, asm_op, unary_op, w, int, ) >>> + >>> +ATOMIC_OPS(and, and, +) >>> +ATOMIC_OPS( or, or, +) >>> +ATOMIC_OPS(xor, xor, +) >> >> The + isn't really needed here as a macro argument; ATOMIC_OPS() >> itself could >> pass it to ATOMIC_FETCH_OP(). I also wonder why ATOMIC_OPS() has both >> "op" and >> "asm_op", when both are uniformly the same. > It is needed for the case when sub operation is implemented using add > plus negative number: > +ATOMIC_OPS(sub, add, +, -)
Except there's no such case right here. Jan
