Re: [Xen-devel] [PATCH XEN v3 14/22] tools: foreignmemory: provide xenforeignmemory_unmap.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-10-07 at 16:20 +0100, Andrew Cooper wrote:
> On 07/10/15 16:16, Ian Campbell wrote:
> > On Wed, 2015-10-07 at 16:03 +0100, Andrew Cooper wrote:
> > > On 07/10/15 15:15, Ian Campbell wrote:
> > > 
> > > What is the plan WRT fixing the existing APIs?
> > Which ones do you mean? The xc_map_foreign_* which aren't moved here?
> > 
> > My intention is to deprecate them and switch everything over to the API
> > provided by this library. IOW xenforeignmemory_map() will be the sole
> > (at
> > least ABI stable way) way to map foreign memory.
> > 
> > I don't want to go replicate the "there's ten ways to do it" aspect of
> > the
> > current interfaces in this new library.
> > 
> > I think the selected interface (which matches the old _bulk one)
> > provides
> > sufficient flexibility to be usable going forward. Evidence of this is
> > that
> > all the old libxc interfaces are now implemented in terms of it.
> 
> Sorry about not being clear.  I meant "At what point do we fix the
> (eventual) API in the new libraries", with reference to the suggested
> s/unsigned int/size_t/ change.

Ah, I think we should aim to release 4.7 with this being declared stable.

I don't foresee the s/unsigned int/size_t/ in libxenforeignmemory being
especially problematic wrt that. There are only a handful of users in tree,
to update and the rest are still using the legacy xc_map_foreign wrappers,
which would be the appropriate place for any impedance matching until those
users get ported over.

Ian.

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