From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 3/3] tools: sched: add support for 'null' scheduler Date: Thu, 6 Apr 2017 17:18:33 +0200 Message-ID: <1491491913.18721.22.camel@citrix.com> References: <148977585611.29510.906390949919041674.stgit@Palanthas.fritz.box> <148977619315.29510.17519562424807312146.stgit@Palanthas.fritz.box> <8c57725d-4bb7-7bd2-c74f-24486531ce94@citrix.com> <1491475775.18721.14.camel@citrix.com> <7f8ce88d-6f0b-196b-b237-f4213d12a6cc@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1867840193825311344==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cw9BN-0007es-5t for xen-devel@lists.xenproject.org; Thu, 06 Apr 2017 15:18:45 +0000 In-Reply-To: <7f8ce88d-6f0b-196b-b237-f4213d12a6cc@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Wei Liu , Julien Grall , Ian Jackson List-Id: xen-devel@lists.xenproject.org --===============1867840193825311344== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-OA6lL7QNTQF8/WZEURei" --=-OA6lL7QNTQF8/WZEURei Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-04-06 at 14:59 +0100, George Dunlap wrote: > On 06/04/17 11:49, Dario Faggioli wrote: > >=20 > > If that fails (I've tried that), domain creation fails too. So > > either > > it returns success, or we'd have to modify (at least) > > liblx__build_post(), teaching it about acceptable failures. > >=20 > > OTOH, we indeed could return success for domain_get() too, for the > > sake > > of having the two above functions return the same. But I really > > think > > that call should fail, as an indication to the callers that they > > won't > > get the value of any parameter for this scheduler. >=20 > I see.=C2=A0=C2=A0So if *our* code doesn't know that there aren't any > parameters > to set, that's OK; but if *other people's code doesn't know that > there > aren't any parameters to get, it needs to be changed to know > that.=C2=A0=C2=A0Got > it. ;-) >=20 Of course! I mean, there must be some advantages and benefits in being *us*! :-D Actually, jokes apart, this is indeed asymmetric, but looks fair to me. As in, _any_ caller (either xl/libxl or external) will see libxl_domain_sched_params_set() succeeding, as well as _any_ caller (either xl/libxl or external) will see libxl_domain_sched_params_get() failing. :-) > There is a sort of mathematical logic to the idea that setting a null > set of parameters should always succeed; and it's certainly > convenient > for tools to be able to always just call > libxl_domain_sched_params_set() > without having to check what scheduler is there.=C2=A0=C2=A0But the same = logic > I > think applies to get(), so I would say to return 0 for both. >=20 I understand your point, and I'm happy to do that. > But Wei and Ian have the final say. >=20 Wei acked this patch in v1 (20170321170902.ndk6h5ylyfkk4coo@citrix.com) but that was before you raised this, so I'm happy to resend with this changed, and doing whatever he prefers with his ack. Wei? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-OA6lL7QNTQF8/WZEURei 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 iQIcBAABCAAGBQJY5lxJAAoJEBZCeImluHPuhtcQANiaW46WdU+Nd8oXoQZhtMNK yr2JM4xy90mclaVJiSxEAFF75TLLSkBy3k4hkRlJWxy/UddCZaKfIkhEvtGQAnTB os1M6j7m7yojj594P+6fCwPaf7+ih2fTyQZT0fdNfnxgKYQMLg14yC6RTLIP9NnK TpYbjzHKT+4KcE+Mf4mODIfj+3HjF8YTm0YPOjMH1PZ7rZzFrgrO/YsTxXapmpj5 3AvFN1ESG+AbaFs448hxWS1abTst5pMaeewUoMlBg+z2IcGJ4Wkz8/9zR5K0C6Np 7QpWEf4D9WAjyhz/qMZXra3PcrKFqkuxWMvhvbYxPlz2LA0onypwhTSdo4iaeSDs NXC2dLIiQrY7ySzJafOKXDNuJM1MhtnXxzOEyMKi7ZjHAo1nk3aSlUbAEpJa3T0M mWeeOro5LrHu6V+DyrBU5RP/xXh/whuuGvhzsH1xh/snqONiQM0YkHN0HS+C+YWI YwgbjmJw0IrCNKCmDezg47w3GXzRW4QVI07ZGG45Z+JwhcRgDp7pD+J978FjHjqs pqurzP/zaWZyEliPIkM/VtRhMK2OKTbElgn8BKQs/3YZJffucFxMVHeIHFSbVhod 7ktWUTYx1mLZHuAMNwlA4ciUe336yNLekTBE0odKmKseqemgWmh9Kozo5Hdur5r/ 1eVhgPFiCR01V4tfO34n =WCmC -----END PGP SIGNATURE----- --=-OA6lL7QNTQF8/WZEURei-- --===============1867840193825311344== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1867840193825311344==--