Message ID | 5044B86C.1070301@redhat.com |
---|---|
State | New |
Headers | show |
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 ... > 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? cheers, Gerd
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
Hi, > 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. Ok, too much trouble, lets skip it then. We'll do it just after the 1.2 release so there is time for people to adapt before 1.3 gets released. Applied patches, fixed up codestyle, reordered to group patches, pushed to usb-next. cheers, Gerd