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

Re: [Xen-devel] [PATCH v2] sched: credit2: respect per-vcpu hard affinity



On Tue, 2015-03-03 at 09:12 +0000, Jan Beulich wrote:
> >>> On 03.03.15 at 04:15, <dario.faggioli@xxxxxxxxxx> wrote:
> > On Sun, 2015-02-08 at 17:45 -1000, Justin T. Weaver wrote:

> >> +#define csched2_cpumask cpumask[smp_processor_id()]
> >> +
> > I like the idea, but put the right side between parentheses.
> 
> Parentheses? Why? There's no operator with higher precedence
> than postfix ones.
> 
There certainly isn't. The why is my personal taste, mostly, which does
not count much, I know, so I grep-ed around the sources and found other
similar examples which have parentheses, and so I went ahead and asked.

However, I can certainly live without them. :-)


> >> +static int get_safe_pcpu(struct csched2_vcpu *svc)
> >> +{
> >>
> > I also don't like the name... __choose_cpu() maybe ?
> 
> Why is everyone liking these double underscore prefixed names so
> much? They're in conflict with the library name space and hence
> should be avoided. Single underscore prefixed names (and the
> underscore not followed by an upper case letter) is what the
> standard sets aside for file scope (i.e. static) identifiers.
> 
Well, I'm not sure I know why, but --from a purely aesthetic point of
view-- I actually like __foo more than _foo. However, the main reason
why I'm suggesting it here, is to follow suit, since __foo is what is
always used (in sched_credit2.c, but also in most of other files AFAICT)
for similar functions.

I see the point you're making, and I can live with _choose_cpu(), but
the result would look a bit inconsistent, IMO.

Regards,
Dario

Attachment: signature.asc
Description: This is a digitally signed message part

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