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

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



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.

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