[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |