Re: [Xen-devel] [PATCH RFC 09/35] Add cpumask_next_zero set_cpu_present and possible

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.02.15 at 19:47, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Wed, 4 Feb 2015, parth.dixit@xxxxxxxxxx wrote:
>> +static DECLARE_BITMAP(cpu_possible_bits, NR_CPUS) __read_mostly;
> 
> ARM already has cpu_possible_map. x86 seems to be able to cope with
> having ACPI without this map.
> 
> If you want to introduce it, you should explain why x86 needs this map.

The more that we specifically got rid of it a few years back.

>> @@ -295,6 +296,22 @@ static inline int cpulist_scnprintf(char *buf, int len,
>>  }
>>  
>>  /*
>> + * cpumask_next_zero - get the next unset cpu in a cpumask
>> + * @n: the cpu prior to the place to search (ie. return will be > @n)
>> + * @srcp: the cpumask pointer
>> + *
>> + * Returns >= nr_cpu_ids if no further cpus unset.
>> + */
>> +static inline unsigned int cpumask_next_zero(int n, const cpumask_t *srcp)
>> +{
>> +    /* -1 is a legal arg here. */
>> +    if (n != -1)
>> +        cpumask_check(n);
>> +
>> +    return find_next_zero_bit(srcp->bits, nr_cpu_ids, n+1);
> 
>        return min_t(int, nr_cpu_ids, find_next_zero_bit(srcp->bits, 
> nr_cpu_ids, n + 1));

For one certainly not "int" when the function returns "unsigned int".
And then I don't see the need for the min() in the first place. Callers
ought to check  < or >= nr_cpu_ids anyway. E.g. I'd rather see this
dropped from cpumask_next() and cpumask_first() too, fixing
eventual callers making wrong assumptions (like cpumask_cycle()).

Jan


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