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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel