From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v10 04/11] xl: enable getting and setting soft affinity Date: Fri, 27 Jun 2014 15:45:23 +0200 Message-ID: <1403876723.8515.26.camel@Solace> References: <20140620161751.450.15846.stgit@Solace> <20140620161920.450.42338.stgit@Solace> <1403872390.3169.12.camel@kazak.uk.xensource.com> <1403875085.8515.21.camel@Solace> <1403875347.3169.37.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1991973214776683823==" Return-path: In-Reply-To: <1403875347.3169.37.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: Andrew.Cooper3@citrix.com, Ian.Jackson@citrix.com, Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============1991973214776683823== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qoZxad6Eb3iiHpcs2B4w" --=-qoZxad6Eb3iiHpcs2B4w Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2014-06-27 at 14:22 +0100, Ian Campbell wrote: > On Fri, 2014-06-27 at 15:18 +0200, Dario Faggioli wrote: >=20 > > That's weird, > > as I just performed a clean build of that scenario to verify this, and > > it ended without errors for me. > >=20 > > It's even more strange as the patch contains the hunk below, which is > > specifically meant at avoiding what you report... :-O >=20 > But strtok_r takes a non-const char *, so when you pass the now const > cpu to it you get exactly this error, don't you? >=20 Right. > > --- a/tools/libxl/xl_cmdimpl.c > > +++ b/tools/libxl/xl_cmdimpl.c > > @@ -656,7 +656,7 @@ static int update_cpumap_range(const char *str, > > libxl_bitmap *cpumap) > > * single cpus or as eintire NUMA nodes) and turns it into the > > * corresponding libxl_bitmap (in cpumap). > > */ > > -static int vcpupin_parse(char *cpu, libxl_bitmap *cpumap) > > +static int vcpupin_parse(const char *cpu, libxl_bitmap *cpumap) > > { > > char *ptr, *saveptr =3D NULL; > > int rc =3D 0; > >=20 Yeah, I was looking at this hunk 'backward' mind-tricked by the fact that it compiles cleanly for me here. :-/ > > Anyway, to be sure, I just compile tested the full series, patch after > > patch, and that also went well. > >=20 > > I'm not sure what's going on! >=20 > My compiler is stricter than yours? >=20 > I'm building on Debian Wheezy, specifically on the machine "cosworth" > here in Cambridge. You should have access... >=20 Well, looks like it's strictier, which I find weird, for issues like this one. I'm building on Debian Sid, with gcc 4.9, which proved elsewhere to be strictier (see the =3DNULL in this series, as well as the blktap2 issue) rather than looser! Anyway, I'll change this and try with Wheezy's compiler before resubmitting. Thanks, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-qoZxad6Eb3iiHpcs2B4w 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 iEYEABECAAYFAlOtdXMACgkQk4XaBE3IOsTrmQCfewHs3lrEcKHzHEXm3tto/Uvj v08AoKhb/N3q7OU11G5is1pUEbfULEgS =9x0q -----END PGP SIGNATURE----- --=-qoZxad6Eb3iiHpcs2B4w-- --===============1991973214776683823== 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 --===============1991973214776683823==--