[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 15/04/16 12:58, Dario Faggioli wrote:
> On Fri, 2016-04-15 at 12:43 +0200, Juergen Gross wrote:
>> On 15/04/16 12:20, Ian Jackson wrote:
>>> Would either of you care to provide a version of my documentation
>>> patch
>>> which answers the questions that my text answers ?  Or shall we
>>> commit
>>> my version and you can edit it in-tree :-).
>> I can provide an updated patch.
> Great.
>>> All I need now is a recipe for the tools to tell what has happened
>>> and
>>> then I can make xl or libxl at least print comprehensible and
>>> correct
>>> error messages...
>> So this boils down to finding an appropriate ESOMETHING replacement
>> for the EBUSY case introduced by the temporary pinning.
> Exactly.
>> I think ENOTEMPTY or EADDRINUSE would fit best.
> I like the latter better.
>> 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:

- when trying to remove the last cpu from a cpupool with active domains
  (EBUSY seems appropriate)
- when trying to move a cpu which is not available in the source cpupool
  or free cpus (I'd suggest ENODEV in this case)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.