From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v9 6/9] libxl/xl: deprecate the build_info->cpumap field Date: Wed, 18 Jun 2014 19:11:25 +0200 Message-ID: <1403111485.21681.45.camel@Solace> References: <20140618141449.21586.55528.stgit@Solace> <20140618142825.21586.54202.stgit@Solace> <1403106794.6568.102.camel@kazak.uk.xensource.com> <1403108817.21681.18.camel@Solace> <1403109886.9627.6.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1229166423688117640==" Return-path: In-Reply-To: <1403109886.9627.6.camel@kazak.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: Ian.Jackson@citrix.com, Andrew.Cooper3@citrix.com, Wei Liu , George.Dunlap@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============1229166423688117640== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9yvNSvdW3BJRQ50h5RWB" --=-9yvNSvdW3BJRQ50h5RWB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2014-06-18 at 17:44 +0100, Ian Campbell wrote: > On Wed, 2014-06-18 at 18:26 +0200, Dario Faggioli wrote: > > On mer, 2014-06-18 at 16:53 +0100, Ian Campbell wrote: > > > On Wed, 2014-06-18 at 16:28 +0200, Dario Faggioli wrote: > > > > @@ -261,6 +262,13 @@ int libxl__build_pre(libxl__gc *gc, uint32_t d= omid, > > > > return rc; > > > > } > > > > libxl_domain_set_nodeaffinity(ctx, domid, &info->nodemap); > > > > + /* > > > > + * info->cpumap is DEPRECATED, but we still want old applicati= ons > > > > + * that may be using it to continue working. > > > > + */ > > > > + if (!libxl_bitmap_is_full(&info->cpumap)) > > >=20 > > > The caller is expected to initialise this unused field to a non-defau= lt > > > state? That doesn't sound right. Did you mean !is_empty? > > >=20 > > Nope. The default for this is to be full, so what I'm checking is reall= y > > that it stayed default. See libxl__domain_build_info_setdefault(): > >=20 > > ... > > if (!b_info->cpumap.size) { > > if (libxl_cpu_bitmap_alloc(CTX, &b_info->cpumap, 0)) > > return ERROR_FAIL; > > libxl_bitmap_set_any(&b_info->cpumap); > > } > > ... > >=20 > > Can I change this? If I can, I think the best would be to remove the > > allocation from libxl__domain_build_info_setdefault(), so that all the > > checks could become something like `if(cpumap.size)'. >=20 > I agree. >=20 > > But does stop allocating the bitmap qualifies as an incompatible API > > change? >=20 > I don't think so, do you think it might for some reason? >=20 Not sure... May an existing application rely on the fact that this is being allocated already? I thought it may, but perhaps I'm misunderstanding when exactly _setdefaults() is supposed to be called. If existing apps do as xl, then it's not an issue to change the default as said above. In fact, in xl, _setdefaults() is called (via freemem()->libxl_domain_need_memory()) after the config file has been parsed already, meaning the user has to allocate cpumap himself if he wants to use it. Is this the intended usage? If yes, I'll happily get rid of that initializer! Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-9yvNSvdW3BJRQ50h5RWB 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 v2.0.22 (GNU/Linux) iEYEABECAAYFAlOhyD0ACgkQk4XaBE3IOsR/BACgqRGnb58P/s+BRo//qL0rRxhU GScAn2dTqlthye+LBXBKCMtw79R3rk1h =HmXD -----END PGP SIGNATURE----- --=-9yvNSvdW3BJRQ50h5RWB-- --===============1229166423688117640== 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 --===============1229166423688117640==--