From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KV9qz-0000GB-9k for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:53:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KV9qt-0000E6-RC for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:53:20 -0400 Received: from [199.232.76.173] (port=46769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KV9qt-0000Dq-Oe for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:53:15 -0400 Received: from wf-out-1314.google.com ([209.85.200.171]:26662) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KV9qr-0001Tj-Lz for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:53:14 -0400 Received: by wf-out-1314.google.com with SMTP id 27so3266887wfd.4 for ; Mon, 18 Aug 2008 11:53:00 -0700 (PDT) Message-ID: <90eb1dc70808181152i17ab0afcmfc6a2c9897854ee5@mail.gmail.com> Date: Mon, 18 Aug 2008 13:52:59 -0500 From: "Javier Guerra" Subject: Re: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect. In-Reply-To: <48A9BDB3.2070906@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <90eb1dc70808151131w3bc285d6u56092226a72ea306@mail.gmail.com> <48A9BDB3.2070906@kernel.org> 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: =?UTF-8?Q?Guido_G=C3=BCnther?= , qemu-devel@nongnu.org, kvm@vger.kernel.org On Mon, Aug 18, 2008 at 1:21 PM, Max Krasnyansky wrote: > Javier Guerra wrote: >> >> what about doing it the other way around? that is, setting udev >> scripts that notify KVM of the hardware changes. > > That seems a bit odd. What if you have more than one QEMU instance and > stuff. there has to be some policy in place to redirect USB devices to each QEMU instance, maybe at startup it could reserve a node in the USB device tree (an USB controller, or maybe a port in a hub). when invoked by udev, some script would consult those reservations and pick the appropriate QEMU yep, it's not trivial, but seems doable with scripts (and a small DB, or maybe a clever filesystem arrangement). -- Javier