From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KodEg-0000QO-Vu for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:06:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KodEg-0000Q0-4C for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:06:18 -0400 Received: from [199.232.76.173] (port=50789 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KodEf-0000Ps-Us for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:06:18 -0400 Received: from mail.codesourcery.com ([65.74.133.4]:59448) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KodEf-0007GM-Mc for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:06:18 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Bluetooth options Date: Sat, 11 Oct 2008 13:06:03 +0100 References: <200809291154.14709.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810111306.13436.paul@codesourcery.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 > > Do we really need 3 different options? Can't everything be done with a > > single -bt option, like it is with -net? > > We can and then the syntax is more like with -net and less like with > -usbdevice, the attached patch does that instead. This looks better to me. > The syntax is now: > -bt hci,null > -bt hci,host[:id] Shouldn't these also have vlan arguments? > -bt hci[,vlan=N] > -bt vhci[,vlan=N] > -bt device:dev[,vlan=N] I think you're being somewhat inconsistent about the option syntax. Using -bt hci for null/"standard" emulated HCI and host hci passthrough but not vhci is particularly unintuitive. The device: qualifier seems like it should be redundant. Unlike USB which is a single master bus, bluetooth network topology is peer-peer with master/slave roles being negotiated on a per-connection basis. Is there any point having a "null" HCI? I'd expect something along the lines of: -bt null[...] -bt hci[...] -bt vhci[...] -bt host[,id=N][...] -bt sdp[...] Obviously this all needs documentation before it is committed ;-) I'm a little confused what the point of the null hci is. Is this a hci that isn't connected to anything else, in which case how is it different to a default hci without anything else on the scatternet. Or is it a dummy test device that just rejects all connections attempts, in which case calling it a HCI seems misleading. > > I'd kinda expect serial bluetooth dongles to be added the same way as USB > > ones, i.e. via -serial options. > > The serial dongle emulated in hw/bt-hci-csr.c has some vendor > extensions so it's not a standard serial dongle. It's attached by the > machine code because this part is not configurable in n8x0. One can > add support for attaching hot-pluggable serial dongles in vl.c if > needed. That sounds like an n8x0 bug. I'm not requiring it be fixed now, but it feels like something that should go away. Paul