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

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



At 11:40 +0000 on 08 Nov (1383907234), Jan Beulich wrote:
> >>> On 08.11.13 at 11:37, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 08/11/13 09:49, Jan Beulich wrote:
> >> 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).

IIRC the __ reservation is a posix thing, not a C one, so it doesn't
apply to us kernel hackers. :)  But actually I would prefer to avoid
using underscore prefixes altogether; I think they're ugly and sometimes
slightly lazy.  (This is a relatively recent conversion -- I realise
the shadow code is full of them!).

I'd be happy with an explicit CODING_STYLE convention that said we
would use them only for the trivial locked vs unlocked distinction.

Cheers,

Tim.

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


 


Rackspace

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