Re: [Xen-devel] [PATCH v2 1/5] x86/hpet: Pre cleanup

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.11.13 at 11:37, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/11/13 09:49, Jan Beulich wrote:
>>>>> On 07.11.13 at 16:28, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>>> * Change some instances of per_cpu($foo, cpu) to this_cpu($foo).  It is
>>>   cleaner to read, and makes it more obvious when the code is poking around 
>>> in
>>>   another cpus data.
>> Documentation wise this is certainly desirable, but since our this_cpu(),
>> other than e.g. Linux'es equivalents, internally does another
>> smp_processor_id(), generate code becomes worse.
> 
> with an "unsigned int cpu = smp_processor_id()" in context, the
> generated code appears to be identical.

In the case here yes. But that changes if there's e.g. a function
call between the two accesses.

>>> * Convert hpet_next_event() to taking a struct hpet_event_channel *, and
>>>   rename to __hpet_set_counter() for a more accurate description of its
>>>   actions.
>> I very much think we should get away from the habit of prefixing
>> symbols with two underscores: Such names are reserved to the
>> compiler/platform, and the standard specifically reserves names
>> starting with one underscore (and not followed by an upper case
>> letter) for use a file scope symbols. This is what I'd like to request
>> be done here.
> 
> So what would you suggest?  Here, all the __$foo() are designed to end
> up similar to large swathes of other Xen code, implying that the
> appropriate spinlock should be held by the caller.
> 
> I am not too fussed which convention we use, so long as it is used
> consistently.

We obviously can't switch to the single-underscore model in one
go. But there are examples of this in the tree already, and I'm
trying to stick to this unless someone tells me not to. In the end
it'll really depend on others' opinions (albeit avoiding to violate the
standard is imo sufficiently strong an argument by itself).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel