From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pT8-0001mL-Az for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:30:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T8pT2-0007Li-9c for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:30:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T8pT1-0007LW-PZ for qemu-devel@nongnu.org; Tue, 04 Sep 2012 05:30:44 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q849Ugf3027443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 4 Sep 2012 05:30:42 -0400 Message-ID: <5045CA85.20807@redhat.com> Date: Tue, 04 Sep 2012 11:31:49 +0200 From: Hans de Goede MIME-Version: 1.0 References: <5044B86C.1070301@redhat.com> <5045BD7B.6050500@redhat.com> In-Reply-To: <5045BD7B.6050500@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL for usb-next]: Move usb-redir over to using more usb-core infra + misc ehci fixes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "qemu-devel@nongnu.org" 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