|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 2/2] xentrace: Implement cpu mask range parsing of human values (-c).
On 06/20/2014 08:33 PM, Konrad Rzeszutek Wilk wrote: Hmm, tricksy -- "buflen" may be non-zero above, but then may end up zero in the "} while()" below. This caused me a bit of confusion -- might be worth a comment? This would appear to accept both of the following: -c -5 # equivalent to 0-5 -c 2,-6 # equivalent to 2, 0-6 Is that what you want?If not, maybe in_range needs to be tristate: RANGE_INIT, RANGE_ONE, RANGE_TWO. Alternately, you might consider accepting both "-N" as meaning "0-N", and "N-" as meaning "N-MAX_CPUS". I think you could do that by adding "if(b==0) { b=nmaskbits-1; }" just after the inner loop. The rest of the parsing here looks correct to me. Isn't "-c 1" (i.e., just pinning to a single cpu) a valid option? I think it should be safe to just to strcmp(), if one of your arguments is a static string, shouldn't it? It's not that big a deal to me either way, though. + ret = parse_cpumask(opts.cpu_mask_str); + else + ret = parse_cpumask_range(opts.cpu_mask_str); + } + if ( !ret ) + set_cpu_mask(opts.cpu_mask); Having the "automatically set all bits" feature in set_cpu_mask() seems a bit confusing to me. It also means that you have three distinct malloc() calls for the cpumask (one of which is wrong). Would it make more sense to move the xc_cpumap_alloc() into this function, and then put the "automatically set all bits" as an else to the if(opts.cpu_mask_str) conditional? That way you can see all the possibilities for what cpu_mask might end up in one place; and it automatically fixes the (potential) bug with parse_cpumask() allocating a buffer that's too small. Everything else looks good though. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |