From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 05 of 10 v2] libxl: rename libxl_cpumap to libxl_bitmap Date: Thu, 21 Jun 2012 11:49:49 +0200 Message-ID: <1340272189.4856.7.camel@Solace> References: <5d3cbf2e6370d1989bcd.1339779873@Solace> <1340269942.21872.26.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2481638585428177731==" Return-path: In-Reply-To: <1340269942.21872.26.camel@zakaz.uk.xensource.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: Ian Campbell Cc: Andre Przywara , Stefano Stabellini , George Dunlap , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============2481638585428177731== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+G9pnVtrphDEkdalKZOD" --=-+G9pnVtrphDEkdalKZOD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-06-21 at 10:12 +0100, Ian Campbell wrote: > On Fri, 2012-06-15 at 18:04 +0100, Dario Faggioli wrote: > > And leave to the caller the burden of knowing and remembering what kind > > of bitmap each instance of libxl_bitmap is. > >=20 > > This is basically just some s/libxl_cpumap/libxl_bitmap/ (and some othe= r > > related interface name substitution, e.g., libxl_for_each_cpu) in a bun= ch > > of files, with no real functional change involved. > >=20 > > A specific allocation helper is introduced, besides libxl_bitmap_alloc(= ). > > It is called libxl_cpu_bitmap_alloc() and is meant at substituting the = old > > libxl_cpumap_alloc(). It is just something easier to use in cases where= one > > wants to allocate a libxl_bitmap that is going to serve as a cpu map. > >=20 > > This is because we want to be able to deal with both cpu and NUMA node > > maps, but we don't want to duplicate all the various helpers and wrappe= rs. >=20 > FWIW I'd have been perfectly happy with a bunch of=20 > #define for_each_cpu(mumble) for_each_bit(mumble) > type stuff, but I think Ian J and yourself didn't like those which I'm > also fine with. >=20 Well, I'm fine with both approaches, actually. However, I've been asked by Ian during last round to kill the duplication as much as I can, and here it is what I came out with. :-) That being said, if it's just a matter of adding back a couple of libxl_for_each_{set_}cpu as a define to libxl_for_each_{set_} bit, I could well do that, as it looks a "reasonable" amount of wrapper duplication to me... > > Signed-off-by: Dario Faggioli > > diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c > > --- a/tools/libxl/libxl_json.c > > +++ b/tools/libxl/libxl_json.c > > @@ -99,8 +99,8 @@ yajl_gen_status libxl_uuid_gen_json(yajl > > return yajl_gen_string(hand, (const unsigned char *)buf, LIBXL_UUI= D_FMTLEN); > > } > >=20 > > -yajl_gen_status libxl_cpumap_gen_json(yajl_gen hand, > > - libxl_cpumap *cpumap) > > +yajl_gen_status libxl_bitmap_gen_json(yajl_gen hand, > > + libxl_bitmap *cpumap) >=20 > Minor nit: You likely meant to rename cpumap in the argument list too. >=20 In this case, I sure did, thanks for pointing it out. > Even with that minor nit: >=20 > Acked-by: Ian Campbell >=20 Good! I'll fix the nit, as I have to resubmit anyway. :-P Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-+G9pnVtrphDEkdalKZOD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk/i7j0ACgkQk4XaBE3IOsSnHQCgn6VVrKWi4keM3tdIict+vjk0 ybwAn3yEsiwMQVkjaqX5nnlQ5PKLeIMi =Mq4G -----END PGP SIGNATURE----- --=-+G9pnVtrphDEkdalKZOD-- --===============2481638585428177731== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2481638585428177731==--