[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |