Re: [Xen-devel] [PATCH XEN v6 14/32] tools: Remove xc_map_foreign_batch

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-12-10 at 15:21 +0000, George Dunlap wrote:
> On 03/12/15 11:22, Ian Campbell wrote:
> > It can trivially be replaced by xc_map_foreign_pages which is the
> > interface I want to move to going forward (by standardising on _bulk
> > but handling err=NULL as _pages does).
> > 
> > The callers of _batch are checking a mixture of a NULL return or
> > looking to see if the top nibble of the (usually sole) mfn they pass
> > has been modified to be non-zero to detect errors. _pages never
> > modifies the mfn it was given (it's const) and returns NULL on
> > failure, so adjust the error handling where necessary. Some callers
> > use a copy of the mfn array, for reuse on failure with _batch, which
> > is no longer necessary as _pages doesn't modify the array, however I
> > haven't cleaned that up here.
> > 
> > This reduces the twist maze of xc_map_foreign_* by one, which will be
> > useful when trying to come up with an underlying stable interface.
> > 
> > NetBSD and Solaris implemented xc_map_foreign_bulk in terms of
> > xc_map_foreign_batch via a compat layer, so xc_map_foreign_batch
> > becomes an internal osdep for them. New OS ports should always
> > implement xc_map_foreign_bulk instead.
> 
> "New OS ports should always implement xc_map_foreign_pages instead"?

"It's complicated" ;-).

New ports should indeed implement the bulk interface, which will in a later
patch become the API which libxenforeignmemory provides. Then the _pages
style interface comes via a that API providing a mode which is compatible
with that way of use (tolerating passing a NULL err array).

Given that the advice here is going to be superceded pretty soon in this
series, I think I will therefore just drop that final sentence.

> Other than that:
> 
> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>

I'll take the liberty of assuming this still applies with the change
discussed above, please let me know if not.

Cheers,
Ian.

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