From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KV9tr-0001AB-PG for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:56:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KV9tp-00019b-8T for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:56:18 -0400 Received: from [199.232.76.173] (port=42320 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KV9tp-00019U-4g for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:56:17 -0400 Received: from mail2.shareable.org ([80.68.89.115]:44384) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KV9to-00023C-R5 for qemu-devel@nongnu.org; Mon, 18 Aug 2008 14:56:16 -0400 Date: Mon, 18 Aug 2008 19:56:13 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect. Message-ID: <20080818185613.GA20308@shareable.org> 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> <90eb1dc70808181152i17ab0afcmfc6a2c9897854ee5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90eb1dc70808181152i17ab0afcmfc6a2c9897854ee5@mail.gmail.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Guido =?iso-8859-1?Q?G=FCnther?= , kvm@vger.kernel.org, Max Krasnyansky Javier Guerra wrote: > 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). I think that's more or less how udev is *supposed* to be used. It's weird for a bit, then it makes sense. Especially as it can integrate nicely with distro scripts, e.g. for networking. But HAL and PolicyKit etc. turn it all on its head and you soon get lost in a twisty maze of configuration files. -- Jamie