From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRmXu-0006yz-1Q for qemu-devel@nongnu.org; Wed, 01 Jun 2011 10:37:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRmXs-000215-0N for qemu-devel@nongnu.org; Wed, 01 Jun 2011 10:37:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRmXr-00020z-IK for qemu-devel@nongnu.org; Wed, 01 Jun 2011 10:37:15 -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 p51EbEBF002657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Jun 2011 10:37:14 -0400 Message-ID: <4DE64EA9.2040305@redhat.com> Date: Wed, 01 Jun 2011 16:37:29 +0200 From: Hans de Goede MIME-Version: 1.0 References: <1306834530-12763-1-git-send-email-hdegoede@redhat.com> <1306834530-12763-8-git-send-email-hdegoede@redhat.com> <4DE63176.7040108@redhat.com> In-Reply-To: <4DE63176.7040108@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/14] usb-linux: If opening a device fails remove it from our filter list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Hi, On 06/01/2011 02:32 PM, Gerd Hoffmann wrote: > On 05/31/11 11:35, Hans de Goede wrote: >> So that we don't retry to open it every 2 seconds flooding stderr with >> error messages. > > The polling here is done intentionally, so the devices catched by the filter show up in the guest automagically as soon as they are plugged in. Just zapping the filter on failure isn't the right thing to do here. Note I'm zapping the filter when we fail to open the device, not when it is not present. This can happen for example when the qemu user does not have rights on the usbfs device node. It seems better to me to print the relevant error once, and then require the user to redo the usb_add / device_add if necessary, then to flood the monitor with repeating the same error every 2 seconds. Note that something like a permission problem (which is the most likely case for opening a device failing once we've found it) won't go away by itself. > We could try to do something more clever than polling sysfs every two seconds though, such using inotify to watch /sys/bus/usb/devices for new devices poping up. That would also result in trying to open the device ones, and if that fails give up, I don't see the difference. Actually the user experience would be worse, because the proper sequence in case of a permission problem would go from: usb_add see error fix permission usb_add to: usb_add see error fix permission usb_del usb_add Regards, Hans