From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KodwK-0003z2-Jm for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:51:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KodwJ-0003yh-JR for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:51:23 -0400 Received: from [199.232.76.173] (port=40444 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KodwJ-0003ye-DD for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:51:23 -0400 Received: from rv-out-0708.google.com ([209.85.198.241]:13900) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KodwJ-0005fJ-9H for qemu-devel@nongnu.org; Sat, 11 Oct 2008 08:51:23 -0400 Received: by rv-out-0708.google.com with SMTP id f25so845237rvb.22 for ; Sat, 11 Oct 2008 05:51:21 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 14:51:21 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] Bluetooth options In-Reply-To: <200810111306.13436.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809291154.14709.paul@codesourcery.com> <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: Paul Brook Cc: qemu-devel@nongnu.org 2008/10/11 Paul Brook : >> > 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. -bt hci and -bt vhci do different things, this is why I wanted them separate first. As explained earalier there are two parts in a hci: the transport layer (connecting the HCI to the cpu or other busses) and the lower layers (the HCIs logic (firmware) and its baseband radio). The transport layer is part of the machine definition: a machine with an onboard serial dongle already determines we will be using the UART transport, the other transport is USB. -bt hci only lets you choose what the lower layers do. -bt vhci defines both a transport layer and the logic. The transport is VHCI (linux specific thing) and as opposed to -bt hci it doesn't connect the radio with the virtual cpu, it connects with the host's software. It would be perhaps better explained with a diagram. Connecting to VHCI and providing the host with a "null" or passthrough hci wouldn't make much sense. > > 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. My idea was device: is anything that isn't part of the emulated computer, it's separate device that happens to be in range. > > Is there any point having a "null" HCI? Not really, other than saving resources (it is like operation without -usb if compared to USB). > > I'd expect something along the lines of: > > -bt null[...] > -bt hci[...] > -bt vhci[...] > -bt host[,id=N][...] > -bt sdp[...] -bt hci, -bt null and -bt host are different than the rest because they use up a kind of resource. If the emulated machine is defined to have three bt HCIs in it (say three serial bt adapters), the first -bt hci/null/host option will relate to the first of these adapters, the n-th option will relate to n-th adapter and any adapters that are left in the machine will be "null". > > Obviously this all needs documentation before it is committed ;-) Right. > > 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. It's a (non-compliant) HCI that doesn't respond to any host command, as if the firmware had locked up. It doesn't even have a radio so it's not in any vlan. The transport layer (UART, USB, VHCI) lets a host write commands to a HCI and receives events in response from the lower layers. The commands written don't have to have any effect on the radio, they talk to firmware running on the HCI. "null" just ignores the commands and never emitts events. "host" writes the commands to a physical hci, so again it's not in any qemu vlan. > >> > 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. No, it's simply the n8x0 main pcb contains a bluetooth HCI + radio (it could be even same chip as the main cpu). The HCI supports some vendor extensions. Consequently this is the machine that hw/nseries.c defines. Cheers