Re: [PATCH v9 6/9] libxl/xl: deprecate the build_info->cpumap field

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2628 bytes --]

On gio, 2014-06-19 at 12:06 +0100, Wei Liu wrote:
> On Wed, Jun 18, 2014 at 06:40:30PM +0200, Dario Faggioli wrote:

> > I'm not sure we can change it like that, without it being considered an
> > API compatibility breakage.... If we can, I'm all for it (if you
> > remember, was trying to do right that in v8).
> > 
> 
> I think this is library internal details. As long as the application
> sees the same behavior then we are fine.
> 
I've looked at the code more closely, understood better how
*_setdefaults() works, and have come to the same determination.

> In V8 setting the default value and honoring cpumap are both removed so
> that's wrong. 
>
Sure. And in fact, what I want --and am doing for v10-- is to kill the
initializer in libxl__build_info_setdefaults() (as it was being done in
v8) while keeping the honoring, if the map is allocated and used by the
caller (as you and Ian suggested, and as it was in v9).

> If you choose to not set the full map then check the size
> later I think it's also OK. That implies making the default value from a
> full bitmap to an empty bitmap, but it's all library internal
> implementation. The application still sees the same behavior.
> 
Not an empty bitmap: a 'not-even-allocated bitmap' (which may be what
you meant already, but you know, one better be sure :-P ).

> > > Shouldn't it be !libxl_bitmap_is_empty?
> > > 
> > Nope (see above).
> > 
> 
> OK. If you don't use empty bitmap as default value. It is probably a bit
> hard to WARN at this point because you cannot distinguish whether a
> "full" bitmap is the "default value" or "user specified value". Probably
> you can do it in libxl__domain_build_info_setdefault if you stick with
> the full bitmap approach?
> 
That is exactly why I want to back off from the "full bitmap as default"
thing! :-) It was a very bad choice (to which, I must say, covering my
head with ashes, I contributed myself... but, in my defense, it were my
very early Xen days... :-/)

And the problem it's not even this new WARN, it's already there in the
code, and there are already decisions being made out of it (as you've
seen yourself!), which are all suffering for that same issue you are
rising here.

Let me state this once more: I'm very happy of being steering away from
this. :-)

Thanks and 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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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