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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Fri, Dec 11, 2015 at 3:42 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> 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.

Oh, right -- I assumed that you'd just missed a string replace
somewhere.  Yes, the Ack still stands.

 -George

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