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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

>>> On 07.06.18 at 17:21, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Ian Jackson [mailto:ian.jackson@xxxxxxxxxx]
>> Sent: 07 June 2018 15:21
>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>> Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>; Jan Beulich
>> <JBeulich@xxxxxxxx>; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Wei
>> Liu <wei.liu2@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; xen-
>> devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; Konrad Rzeszutek Wilk
>> <konrad.wilk@xxxxxxxxxx>; Daniel de Graaf <dgdegra@xxxxxxxxxxxxx>; Tim
>> (Xen.org) <tim@xxxxxxx>
>> Subject: RE: [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op
>> Paul Durrant writes ("RE: [PATCH 5/7] public / x86: introduce
>> __HYPERCALL_iommu_op"):
>> > FWIW Linux appears to use a single '_' prefix and no suffix.
>> This practice of scattering underscores about, apparently at random,
>> is baffling to me.
>> It doesn't look like most of the people who do it are aware of the
>> rules.  For example, #defining any identifier starting __ is a licence
>> to the compiler to stuff demons up your nose.
>> We should do this:
>>   #define XEN_PUBLIC_IOMMU_OP_H
>> which is (i) not in any of the compiler's namespaces (ii) has XEN_ at
>> the beginning so we can justify thinking that it won't clash with
>> anyone else's identifiers (Iii) will never clash with any of our own
>> because it ends in _H.
> Sounds ok to me. Patch to CODING_STYLE?

I've sent a patch already, but that's addressing the other aspect. I
don't think CODING_STYLE needs to talk about conforming with
language standards. To reduce the risk of misguiding people, I agree
we should see about reducing the number of existing violations. We've
been doing this for quite a while, but the process is rather slow going,
largely because so far we mostly change things we need to touch


Xen-devel mailing list



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