[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 22/25] x86/HVM: do actual CMPXCHG in hvmemul_cmpxchg()

>>> On 05.02.18 at 17:57, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/02/18 16:49, Jan Beulich wrote:
>>>>> On 05.02.18 at 17:09, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 05/02/18 08:32, Jan Beulich wrote:
>>>>>>> On 02.02.18 at 17:36, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>> --- a/xen/include/asm-x86/system.h
>>>>>> +++ b/xen/include/asm-x86/system.h
>>>>>> @@ -110,6 +110,38 @@ static always_inline unsigned long __cmp
>>>>>>      return old;
>>>>>>  }
>>>>>> +static always_inline unsigned long cmpxchg_local_(
>>>>> unlocked_cmpxchg() ?
>>>> Not in line with our current naming scheme.
>>> Its rather more in line than introducing a local_ suffix.  Trailing
>>> underscores are almost non-existant, and as far as I can tell, used
>>> exclusively in the internals of the compat code.
>> Well, the name choice started from Linux'es cmpxchg_local(), of
>> which the function introduced here would be a helper. I'd like to
>> stick to the Linux inherited naming scheme (read: I want to keep
>> the "cmpxchg_local" part), but I don't insist on the trailing
>> underscore (which I only use here [and elsewhere] in preference
>> of name space violating leading ones). I'd just need a suggestion
>> towards an alternative you could live with, and fitting the outlined
>> criteria.
> cmpxchg_local() would be better than with a trailing underscore.
> Seeing as it matches the Linux naming scheme, using exactly
> cmpxchg_local() would be the logical move.

Note how I've said "of which the function introduced here would be
a helper": cmpxchg_local() should have no size parameter.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.