Re: [Xen-devel] [PATCH 3/3] xen: Document XEN_SYSCTL_CPUPOOL_OP_RMCPU anomalous EBUSY result

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Fri, 2016-04-15 at 15:20 +0200, Juergen Gross wrote:
> On 15/04/16 12:58, Dario Faggioli wrote:
> > 
> > On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote:
> > > 
> > > The EBUSY returns of not successful repair attempts (trying to
> > > assign
> > > a
> > > cpu to another cpupool) should be changed to e.g. EADDRNOTAVAIL?
> > > 
> > 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:
> 
I know...

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

> - when trying to move a cpu which is not available in the source
> cpupool
>   or free cpus (I'd suggest ENODEV in this case)
> 
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
-- 
<<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)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel