From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KV5Sd-0003Ww-Kl for qemu-devel@nongnu.org; Mon, 18 Aug 2008 10:11:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KV5Sc-0003WT-5L for qemu-devel@nongnu.org; Mon, 18 Aug 2008 10:11:55 -0400 Received: from [199.232.76.173] (port=34980 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KV5Sc-0003WQ-03 for qemu-devel@nongnu.org; Mon, 18 Aug 2008 10:11:54 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:47192) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KV5Sb-0001vD-Pm for qemu-devel@nongnu.org; Mon, 18 Aug 2008 10:11:53 -0400 Received: by gxk12 with SMTP id 12so3500037gxk.10 for ; Mon, 18 Aug 2008 07:11:53 -0700 (PDT) Message-ID: <48A982FF.8070903@codemonkey.ws> Date: Mon, 18 Aug 2008 09:11:11 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect. References: <48A46033.3070200@codemonkey.ws> <48A489D3.5070900@kernel.org> <48A493DE.40506@codemonkey.ws> <48A496E9.2030800@kernel.org> <48A49878.1010502@codemonkey.ws> <20080815074638.GA31016@bogon.ms20.nix> <48A5C9F2.5080400@kernel.org> In-Reply-To: <48A5C9F2.5080400@kernel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Krasnyansky Cc: =?ISO-8859-1?Q?Guido_G=FCnther?= , qemu-devel@nongnu.org, kvm@vger.kernel.org Max Krasnyansky wrote: > Guido Günther wrote: > >> What about /dev/bus/usb - it supports inotify fine on udev? >> > > Yes it should since it's a regular filesystem. > I was thinking of this too since /proc/bus/usb is deprecated in favor of /dev/bus/usb. If someone was willing to port QEMU to /dev/bus/usb, it would be greatly appreciated! Regards, Anthony Liguori > Now inotify based solution probably won't be pretty because we'd have to > monitor each subdir. ie When new device get added top level /dev/bus/usb is > not modified, what does get modified is /dev/bus/usb// directory so > we'd have to monitor /dev/bus/usb and dynamically register/unregister monitors > for each /dev/bus/usb//. > Maybe it won't be that bad. If I get a chance I'll give it a shot. > > btw Interface to HAL might still be useful in general to monitor other device > classes that we may want to automatically assign to the VMs. So I'll play > around with that too (some day :)). > > Max > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >