Re: [Xen-devel] [PATCH v5 12/17] xen/libxc: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.12.13 at 11:59, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
> Well, actually, I only asked what we should be returning from
> DOMCTL_vcpu_setaffinity, and never mentioned DOMCTL_vcpu_getaffinity
> because I seriously thought there was no need to discuss what the latter
> should be returning, and whether or not the two return values should
> match.

And I would also have doubted that I ever said to do something
intentionally inconsistent...

> I thought, and still think, it's pretty obvious there must be a way for
> the user to retrieve what he has set, independently on the various
> intersections between online, hard affinity, etc, mustn't it? Well, that
> way is using DOMCTL_get_vcpuaffinity.
> 
> Actually, if DOMCTL_vcpu_setaffinity an DOMCTL_vcpu_getaffinity would be
> returning the exact same thing, why are we bothering having both doing
> that? It would have been pretty easy to just, in the toolstack, issue a
> call to _get_ right after a _set_ and check. No, the point was to have
> _set_ return something actually useful, i.e., something that can't be
> retrieved in any other way, as an indication of how effective the set
> operation itself was. That, by definition, makes what _set_ and _get_
> returns different, and it may be my fault to no have mentioned this
> clearly in our earlier discussions, but I really was giving it for
> granted. :-/
> 
> That being said, I of course can say something about this in some
> docs/header. Actually, the following patch does that quite thoroughly, I
> think, in tools/libxc/xenctrl.h. I can certainly add something similar
> in Xen's public .h files.

As said - as long as there is proper reasoning and at least a brief
explanation in the public header (xenctrl.h not being considered
"public" in the context here"), I'm fine with the returned masks
differing.

Jan


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