From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH v3 03/13] xen: introduce cpumask_from_bitmap Date: Thu, 25 Apr 2013 15:27:45 +0100 Message-ID: References: <5179428602000078000D0C34@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5179428602000078000D0C34@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Stefano Stabellini Cc: Julien Grall , "Tim (Xen.org)" , "Keir (Xen.org)" , Ian Campbell , xen-devel List-Id: xen-devel@lists.xenproject.org On 25/04/2013 13:49, "Jan Beulich" wrote: >>>>>>> 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". If I am convinced that the usage case is sane, I'll ack a one-use helper. I have no problem with one-use helpers! To me this would be a perfectly reasonable cpumask_t constructor fn. -- Keir > Jan >