Re: [Qemu-devel] Bluetooth options

[andrzej zaborowski]

2008/10/11 Paul Brook <address@hidden>:
>> > 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