From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [PATCH 3/3] xen: Document
 XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result
Date: Fri, 15 Apr 2016 15:33:43 +0200
Message-ID: <1460727223.13871.259.camel@citrix.com>
References: <1460653660-6654-1-git-send-email-ian.jackson@eu.citrix.com>
 <1460653660-6654-4-git-send-email-ian.jackson@eu.citrix.com>
 <570FD25B.3060802@citrix.com>
 <22287.55772.931614.61945@mariner.uk.xensource.com>
 <1460665330.13871.196.camel@citrix.com>
 <22288.49281.920483.206367@mariner.uk.xensource.com>
 <5710C5DD.1090403@suse.com> <1460717913.13871.240.camel@citrix.com>
 <5710EABB.3010003@suse.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5135309798135924887=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5710EABB.3010003@suse.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: Juergen Gross <jgross@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>, George Dunlap <george.dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, Jan Beulich <jbeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

--===============5135309798135924887==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-QIIJeLStLJ23XdH3cIk1"

--=-QIIJeLStLJ23XdH3cIk1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2016-04-15 at 15:20 +0200, Juergen Gross wrote:
> On 15/04/16 12:58, Dario Faggioli wrote:
> >=20
> > On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote:
> > >=C2=A0
> > > The EBUSY returns of not successful repair attempts (trying to
> > > assign
> > > a
> > > cpu to another cpupool) should be changed to e.g. EADDRNOTAVAIL?
> > >=20
> > I'd go for EADDRINUSE and EADDRNOTAVAIL so the two error values are
> > similarly *wrong* hinting an addressing issue, which is more
> > consistent
> > (and would come handy when documenting) than having one pointing at
> > the
> > filesystem and the other at the address space.
> Just saw there are still two cases left where EBUSY will be returned:
>=20
I know...

> - when trying to remove the last cpu from a cpupool with active
> domains
> =C2=A0 (EBUSY seems appropriate)
>
Indeed.

> - when trying to move a cpu which is not available in the source
> cpupool
> =C2=A0 or free cpus (I'd suggest ENODEV in this case)
>=20
Well, in practice, I don't actually think this is too big of a deal. In
fact, I don't think that tools can or need to differentiate their
behavior too much between this and, for instance, the above mentioned
failure.

_However_, if while you're there you're up for making this case
returning ENODEV, it would indeed look like it's more descriptive of
the actual problem, and hence better.

Regards,
Dario
--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-QIIJeLStLJ23XdH3cIk1
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

iEYEABECAAYFAlcQ7bcACgkQk4XaBE3IOsQjNwCfVkZ3TOcSlH2tELb4vHq6MByZ
ymoAn2ZEUwmMSCkeiZFQ52+/rzs8hA12
=g17O
-----END PGP SIGNATURE-----

--=-QIIJeLStLJ23XdH3cIk1--


--===============5135309798135924887==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

--===============5135309798135924887==--