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

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



On Thu, Jun 19, 2014 at 04:00:55PM +0200, Dario Faggioli wrote:
> 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).
> 

I think that will do.

> > 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 ).
> 

Yes, that's what I meant. :-)

Wei.

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


 


Rackspace

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