[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Minios-devel] [PATCH v4 0/<VARIOUS>] Begin to disentangle libxenctrl and provide some stable libraries
On Fri, 20 Nov 2015, Ian Campbell wrote: > On Thu, 2015-11-19 at 16:20 +0000, Stefano Stabellini wrote: > > > > > I think having three or four functions in libxendevicemodel which offer > > > these exact facilities while retaining the underlying (possibly more > > > flexible) functionality in libxenctrl for other users (dombuilder, other > > > in > > > tree tools) would be tolerable. > [...] > > The main question would then be whether libxendevicemodel should wrap > > > libxenctrl in a stable layer or whether it should actually duplicate the > > > functionality in the thin wrappers. > > > > Couldn't we rename the existing libxc calls and make them stable? > > This was sort of what I was getting at a couple of paras earlier (quotes > trimmed to just that bit). > > The current functions are far more flexible than what QEMU requires (and > that flexibility is used by in tree components). ÂI'm not sure we can (or > want to) declare the full breadth of the functionality of e.g. > xc_domain_add_to_physmap and xc_domain_pin_memory_cacheattr as being stable > and it would be much easier to arrive at and agree on a suitable stable > interface for more limited specific functionality. This is a good point. > If we were to just say "xc_domain_add_to_physmap and > xc_domain_pin_memory_cacheattr are now stable" then having them in a > libxendevicemodel would be incorrect, since they are not in any way > specific to device models. > > > > ÂÂKeep > > in mind that we already have stable wrappers in QEMU in > > include/hw/xen/xen_common.h. I don't think we need two layers of > > wrappers :-) > > Indeed, but part of the purpose of Xen providing stable libraries is that > external components/users should not need wrappers. > > IOW IMHO the current wrappers in QEMU should, as part of this exercise in > providing stable interfaces, be deprecated and remain only to retain > compatibility with older versions of Xen which lacked the stable > interfaces, with a view to them eventually being removed as support for > those older Xen's is removed from QEMU. I agree that it would be nicer to have the wrapper in Xen, but realistically we won't be able to get rid of the ones in QEMU anytime soon. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |