Re: [Qemu-devel] [PULL for usb-next]: Move usb-redir over to using more usb-core infra + misc ehci fixes

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 09/04/2012 10:36 AM, Gerd Hoffmann wrote:
>    Hi,
>
>> I've made a tree with my current usb-redir work for upstream here:
>> including some more ehci fixes is here, can you please add the
>> patches from there to your usb-next tree?
>
> In general it is better to work against master not usb-next as usb-next
> is a moving target.  A little hard in this case as there is a noticable
> usb queue waiting for 1.3 development open and you have dependencies on
> patches queued up ...
>

Understood, I'll start basing my work on master again once the necessary
deps for my work are in master.

>
>>        usb-redir: Convert to new libusbredirparser 0.5 API
>
> This one adds a hard dependency on the latest libusbredirparser.  Can we
> make this optional without too much fuss, so qemu continues to build
> with older versions, at least for a while?  For example disable live
> migration support if we find an older libusbredir version?

I very carefully designed the libusbredirparser API and ABI so that
extensions could be added without breaking API or ABI, but the problem
is the new 64 bit ids, all callbacks for received packets, and all
helpers for sending packets take the id as a function argument which
is now changing from an uint32_t to an uint64_t, which means break API
and ABI :|

Note that at the wire level the capability negotiation makes things
still work with clients which only do 32 bit ids (which are fine as
long as XHCI is not involved), and like wise 64 bit id capable clients
will work fine with older qemu-s.

Fulfilling your request would mean wrapping 90% of all function
prototypes in hw/usb/redirect.c with #ifdef magic. Which I find rather
ugly. If you prefer the ifdef's over the hard version requirement,
I can do the ifdef-s, but my preference is to just put the hard
version dependency on the latest usbredir in there.

Regards,

Hans