[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
Xen-devel mailing list



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