From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39070 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGHUQ-00075F-SB for qemu-devel@nongnu.org; Wed, 10 Nov 2010 15:41:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PGHUP-0000yN-Q7 for qemu-devel@nongnu.org; Wed, 10 Nov 2010 15:41:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PGHUP-0000xv-JW for qemu-devel@nongnu.org; Wed, 10 Nov 2010 15:41:53 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oAAKfnZ8029048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 10 Nov 2010 15:41:49 -0500 Date: Wed, 10 Nov 2010 22:41:44 +0200 From: Alon Levy Subject: Re: [Qemu-devel] [PATCH 0/3] add usb_detach and usb_attach (v3) Message-ID: <20101110204144.GA19037@playa.tlv.redhat.com> References: <1287642991-21114-1-git-send-email-alevy@redhat.com> <4CC03A2D.9030105@redhat.com> <4CC03C6F.4020304@codemonkey.ws> <20101021132418.GD22958@playa.tlv.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On Wed, Nov 10, 2010 at 04:49:38PM +0100, Markus Armbruster wrote: > Sorry for coming so late to this thread... > > Alon Levy writes: > > > On Thu, Oct 21, 2010 at 08:13:19AM -0500, Anthony Liguori wrote: > >> On 10/21/2010 08:03 AM, Gerd Hoffmann wrote: > >> >On 10/21/10 08:36, Alon Levy wrote: > >> >>v2->v3 changes: > >> >> * add configure parameter > >> >> * fix docs > >> >> > >> >>v2 message: > >> >>This patchset uses id like device_del for attaching/detaching usb > >> >>devices. The first two patches ready the way: > >> >> 1. makes qdev_find_recursive non static and in qdev.h > >> >> 2. adds a usb_device_by_id which goes over the usb buses calling > >> >> qdev_find_recursive > >> >> 3. adds the commands that use usb_device_by_id > >> >> > >> >>Alon Levy (3): > >> >> qdev: make qdev_find_recursive public > >> >> usb: add public usb_device_by_id > >> >> monitor: add usb_attach and usb_detach (v2) > >> >> > >> > > >> >Acked-by: Gerd Hoffmann > >> > >> Okay, I am still confused about the use-case for this and I don't > >> see any further explanation in the commit messages. I've seen > >> "debugging" but can you be a bit more specific about which cases > >> it's needed for? > >> > > > > I use it for debugging the usb-ccid device. I think it's useful for > > any other usb device tests as well. The existing commands are not > > good enough to do a remove/insert of a usb device, since deleting > > a device also deletes any chardev associated with it, and there is > > no monitor command to add a chardev. Also sometimes you don't want > > to close the chardev, just have the guest see a removal/reinsert of > > the device. > [...] > > Let's see whether I get you: detach removes the device, but doesn't > destroy it. The only thing you can do with a detached device is attach > it. Detach+attach is basically the same as del+add with the same > configuration. Except shortcomings in our command set make it > impossible to recreate the configuration sometimes. Correct? So the problems with the current commands from my pov: - device deletion removes associated chardev - no way to do it without removing chardev - no way to add chardev later and use it for device add The outcome of which is that you can't do a guest wise attach/detach from monitor if your device relies on a chardev association. This happens with my passthrough ccid device. > > Questions: > > 1. If we add commands so that you can always recreate the configuration, > is detach+attach still useful? Why? If you make it so you can do a device_del and not remove the chardev, and later device_add using the already existing chardev, then that will be equivalent for me. > > 2. Why is this a USB problem, and not a general problem? In other > words, why usb_{detach,attach}, and not device_{detach,attach}? I guess attach/detach is a don't-free-some-resources del/add. If you think there are users for a device_attach/detach and it makes sense conceptually (what's a detach/attach for an ide bus? for a pci it's pretty clear, for sata, etc.) then you could blow this up to a device specific callback or something like that (assuming that's how you would implement this).