Re: [Xen-devel] [PATCH v3 03/13] xen: introduce cpumask_from_bitmap

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.04.13 at 13:38, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
wrote:
> On Thu, 25 Apr 2013, Jan Beulich wrote:
>> >>> On 25.04.13 at 12:35, Stefano Stabellini 
>> >>> <stefano.stabellini@xxxxxxxxxxxxx>
>> wrote:
>> > On Thu, 25 Apr 2013, Jan Beulich wrote:
>> >> >>> On 25.04.13 at 12:01, Stefano Stabellini 
>> >> >>> <stefano.stabellini@xxxxxxxxxxxxx>
>> >> wrote:
>> >> > On Thu, 25 Apr 2013, Jan Beulich wrote:
>> >> >> >>> On 24.04.13 at 21:07, Stefano Stabellini 
>> >> >> >>> <stefano.stabellini@xxxxxxxxxxxxx> 
> 
>> >> > wrote:
>> >> >> > +static inline cpumask_t cpumask_from_bitmap(unsigned long *bits, 
>> >> >> > int 
>> >> > nr_bits)
>> >> >> > +{
>> >> >> > +    cpumask_t mask;
>> >> >> > +    int len = nr_bits < nr_cpumask_bits ? nr_bits : nr_cpumask_bits;
>> >> >> 
>> >> >> min(nr_bits, nr_cpumask_bits)
>> >> >> 
>> >> >> > +
>> >> >> > +    memset(&mask, 0x00, sizeof(mask));
>> >> >> 
>> >> >> bitmap_zero().
>> >> >> 
>> >> >> > +    bitmap_copy(mask.bits, bits, len);
>> >> >> 
>> >> >> Hard tab.
>> >> >> 
>> >> >> > +
>> >> >> > +    return mask;
>> >> >> > +}
>> >> >> 
>> >> >> And most importantly: Why? This isn't an operation that should
>> >> >> commonly be done, and hence having a utility function for this
>> >> >> seems to invite for abuse rather than really help.
>> >> > 
>> >> > TBH I have done it to address Ian's comment, I don't have a strong
>> >> > opinion on this.
>> >> > However it is true that from an API point of view, cpumask_from_bitmap
>> >> > allows us to cover the new use case without breaking the cpumask
>> >> > abstraction.
>> >> 
>> >> Rather than adding a new abstraction that's used for a single
>> >> special case, and if open coding is undesirable, I'd prefer if you
>> >> used bitmap_to_xenctl_bitmap() plus xenctl_bitmap_to_cpumask()
>> >> if at all possible.
>> > 
>> > Both functions do copy_to/from_guest and use xmalloc, I don't think I
>> > can use them.
>> 
>> Hmm, ugly. But okay then...
> 
> Is that an ack? ;-)

No, this is at best an "I won't object to this anymore, but I still
don't like it".

Jan


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