From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzmRB-0003rt-Cc for qemu-devel@nongnu.org; Thu, 18 Jul 2013 07:31:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzmR9-0006aP-Gl for qemu-devel@nongnu.org; Thu, 18 Jul 2013 07:31:57 -0400 Received: from mail-we0-f181.google.com ([74.125.82.181]:51642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzmR9-0006Zs-9V for qemu-devel@nongnu.org; Thu, 18 Jul 2013 07:31:55 -0400 Received: by mail-we0-f181.google.com with SMTP id p58so2676619wes.26 for ; Thu, 18 Jul 2013 04:31:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20967.52442.308010.563288@mariner.uk.xensource.com> References: <1373624555-4403-1-git-send-email-fabio.fantoni@m2r.biz> <51DFE351.4000102@eu.citrix.com> <51DFF83A.8030802@m2r.biz> <51E021B7.2050808@eu.citrix.com> <51E3BC9B.8080503@m2r.biz> <20967.52442.308010.563288@mariner.uk.xensource.com> Date: Thu, 18 Jul 2013 06:31:53 -0500 Message-ID: From: Anthony Liguori Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH v3] libxl: usb2 and usb3 controller support for upstream qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ian Jackson Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com, George Dunlap , wei.lui2@citrix.com, qemu-devel , Fabio Fantoni , Paolo Bonzini On Thu, Jul 18, 2013 at 6:09 AM, Ian Jackson wrote: > Fabio Fantoni writes ("Re: [PATCH v3] libxl: usb2 and usb3 controller support for upstream qemu"): >> Il 12/07/2013 17:33, George Dunlap ha scritto: >> > On 12/07/13 13:36, Fabio Fantoni wrote: > [someone wrote:] >> >>> I'm just curious, why is this so complicated? Is this likely to be >> >>> fragile and break in the future? > ... >> >> I tried already but there are problems with retrocompatibility: >> >> http://lists.xen.org/archives/html/xen-devel/2013-07/msg00491.html >> >> I was also asking if it is possible to remove some hardcoded options >> >> without breaking something but I had no reply. >> > >> > So this seems to be a response to the first paragraph ("why is this so >> > complicated, is it fragile"). > > I'm afraid that I don't think it's really a sufficient response to > "why is this so complicated, is it fragile?". "I don't know" is not > very convincing :-). It's a multi-function PCI device that provides separate functions for each legacy interface. There are three distinct UHCI interfaces presumably to enable supporting more ports. In an ideal world, we would support this by having a single -device ich-usb that did the right thing but we don't really have a way to model multifunction devices as a single entity today. Hence, the complex command line. The command line interface is a stable interface in QEMU. This interface will not change over time. > My worry would be that these options would change their meaning in the > future, or indeed that the whole edifice which requires callers to > specify things at this excruciating level of detail might (sensibly!) > be abolished. Patches are welcome :-) Seriously, I would love for someone to do proper multi-function support such that we could support hotplugging a multi-function device. The current way of creating each function will always be supported though. Regards, Anthony Liguori > Ian. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH v3] libxl: usb2 and usb3 controller support for upstream qemu Date: Thu, 18 Jul 2013 06:31:53 -0500 Message-ID: References: <1373624555-4403-1-git-send-email-fabio.fantoni@m2r.biz> <51DFE351.4000102@eu.citrix.com> <51DFF83A.8030802@m2r.biz> <51E021B7.2050808@eu.citrix.com> <51E3BC9B.8080503@m2r.biz> <20967.52442.308010.563288@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <20967.52442.308010.563288@mariner.uk.xensource.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Ian Jackson Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, Stefano.Stabellini@eu.citrix.com, George Dunlap , wei.lui2@citrix.com, qemu-devel , Fabio Fantoni , Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On Thu, Jul 18, 2013 at 6:09 AM, Ian Jackson wrote: > Fabio Fantoni writes ("Re: [PATCH v3] libxl: usb2 and usb3 controller support for upstream qemu"): >> Il 12/07/2013 17:33, George Dunlap ha scritto: >> > On 12/07/13 13:36, Fabio Fantoni wrote: > [someone wrote:] >> >>> I'm just curious, why is this so complicated? Is this likely to be >> >>> fragile and break in the future? > ... >> >> I tried already but there are problems with retrocompatibility: >> >> http://lists.xen.org/archives/html/xen-devel/2013-07/msg00491.html >> >> I was also asking if it is possible to remove some hardcoded options >> >> without breaking something but I had no reply. >> > >> > So this seems to be a response to the first paragraph ("why is this so >> > complicated, is it fragile"). > > I'm afraid that I don't think it's really a sufficient response to > "why is this so complicated, is it fragile?". "I don't know" is not > very convincing :-). It's a multi-function PCI device that provides separate functions for each legacy interface. There are three distinct UHCI interfaces presumably to enable supporting more ports. In an ideal world, we would support this by having a single -device ich-usb that did the right thing but we don't really have a way to model multifunction devices as a single entity today. Hence, the complex command line. The command line interface is a stable interface in QEMU. This interface will not change over time. > My worry would be that these options would change their meaning in the > future, or indeed that the whole edifice which requires callers to > specify things at this excruciating level of detail might (sensibly!) > be abolished. Patches are welcome :-) Seriously, I would love for someone to do proper multi-function support such that we could support hotplugging a multi-function device. The current way of creating each function will always be supported though. Regards, Anthony Liguori > Ian. >