[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH, RFC 3/4] qemu: use new (replacement) mmap-batch ioctl



>>> Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 12.01.10 18:25 >>>
>> +#if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
>> +void * __attribute__((__weak__))
>> +xc_map_foreign_bulk(int xc_handle, uint32_t dom, int prot,
>> +                    const xen_pfn_t *, int *err, unsigned int num);
>> +#endif
>
>This is pretty horrible.
>
>This should be done by using the #ifdef arround the call to
>xc_map_foreign_bulk, not by having a weak symbol compared to NULL.

While indeed I wasn't sure about how (or if at all) to put in
backward compatibility, this seemed to be the consolidated place.

Using and #ifdef in the source file doesn't seem nice though, as it
would tie a qemu built against older headers to using the old
interface. But since I'm not sure about the compatibility needs in
the first place, I will listen to whatever you say you deem
appropriate.

>You might consider whether the ability to use the old call is intended
>to last forever.  Probably not, soi you should mark it deprecated.

It is being marked deprecated in a comment; using the respective
__attribute_((__deprecated__)) didn't seem a proper thing in a
header that ought to be consumable by non-GNU compilers.

>> -    phys_ram_base = xc_map_foreign_batch(xc_handle, domid,
>> +    phys_ram_base = xc_map_foreign_pages(xc_handle, domid,
>>                                           PROT_READ|PROT_WRITE,
>>                                           page_array, nr_pages);
>
>I'm not sure I understand this bug I haven't looked at it in any kind
>of detail so it may be correct.

This just follows the libxc changes: Any call to xc_map_foreign_batch()
where the array wasn't looked at for per-page errors just wasn't
correct, and now gets converted to use xc_map_foreign_pages()
instead (which does the error checking on behalf of the caller).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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