* [Qemu-devel] Bluetooth options
@ 2008-09-29 1:27 andrzej zaborowski
2008-09-29 10:54 ` Paul Brook
0 siblings, 1 reply; 5+ messages in thread
From: andrzej zaborowski @ 2008-09-29 1:27 UTC (permalink / raw)
To: qemu-devel mailing list
[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]
Hi,
I added code to emulate various bluetooth hardware but I didn't add
any user interface to set it up or tweak. The attached patch adds
command line switches for doind that but it's not very pretty, any
suggestions to change it will be appreciated.
There are three switches:
-bt xxx
tells qemu how to emulate a given HCI. A HCI is made of two parts,
the transport layer (serial or USB) through which the host issues HCI
commands, and the HCI logic that does something with the commands.
The transport layer is determined by the emulated machine, for example
a machine might have two serial dongles in it, then the first -bt
switch will relate to the dongle on the first serial port and the
second -bt to the other dongle. 'xxx' can be three things:
-bt null
simply ignores any commands, i.e. never gives any response.
-bt hci[,vlan=N]
emulates a virtual HCI more or less according to the
specification. Using -bt hci,vlan=N adds the HCI to scatternet N
(default 0) or creates a new scatternet, which is similar to a qemu
ethernet vlan in that any two devices in the same vlan can connect to
each other.
-bt host[:ID]
connects to the host's dongle named ID (defaults to 'hci0') and
proxies any commands to this dongle. This has some limitations under
Linux and is not very reliable.
-vhci N
emulates a vireual HCI (like -bt hci) that is not connected to any
guest transport and instead opens /dev/vhci to create what appears as
a new dongle to the host bluetooth stack. It will be connected to the
qemu vlan N.
-btdevice dev[,vlan=N]
adds a bluetooth device 'dev' to scatternet N (default 0),
similarly to -usbdevice. The only supported value for 'dev' is
'keyboard' which is like a usb HID keyboard. It doesn't support
authentication (which I think, in case of a keyboard makes it
out-of-spec) but that's easy to implement.
A usb dongle can be added with -usbdevice bt or -usbdevice:xxx where
xxx is same as in -bt xxx (defaults to 'hci,vlan=0'). Monitor usb_add
should also work. It specifies both a transport layer (USB) and the
HCI logic, so no -bt switch is needed. -bt is only useful for machines
with a built-in transciever like the n800/n810.
Regards
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-commandline-options-to-make-use-of-bluetooth-.patch --]
[-- Type: text/x-patch; name=0001-Add-commandline-options-to-make-use-of-bluetooth-.patch, Size: 7669 bytes --]
From 8f10f5a4526f74ceb6c8a5643ca35e633297279d Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski <balrog@zabor.org>
Date: Mon, 29 Sep 2008 02:48:58 +0200
Subject: [PATCH] Add commandline options to make use of bluetooth features, e.g attach
devices.
---
vl.c | 164 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index b19a631..cf913f9 100644
--- a/vl.c
+++ b/vl.c
@@ -5414,6 +5414,105 @@ struct HCIInfo *qemu_next_hci(void)
return hci_table[cur_hci++];
}
+static struct HCIInfo *hci_init(const char *str)
+{
+ char *endp;
+ struct bt_scatternet_s *vlan = 0;
+
+ if (!strcmp(str, "null"))
+ /* bt null */
+ return &null_hci;
+ else if (!strncmp(str, "host", 4) && (str[4] == '\0' || str[4] == ':'))
+ /* bt host[:hciN] */
+ return bt_host_hci(str[4] ? str + 5 : "hci0");
+ else if (!strncmp(str, "hci", 3)) {
+ /* bt hci[,vlan=n] */
+ if (str[3]) {
+ if (!strncmp(str + 3, ",vlan=", 6)) {
+ vlan = qemu_find_bt_vlan(strtol(str + 9, &endp, 0));
+ if (*endp)
+ vlan = 0;
+ }
+ } else
+ vlan = qemu_find_bt_vlan(0);
+ if (vlan)
+ return bt_new_hci(vlan);
+ }
+
+ fprintf(stderr, "qemu: Unknown bluetooth HCI `%s'.\n", str);
+
+ return 0;
+}
+
+static int bt_hci_parse(const char *str)
+{
+ struct HCIInfo *hci;
+ bdaddr_t bdaddr;
+
+ if (nb_hcis >= MAX_NICS) {
+ fprintf(stderr, "qemu: Too many bluetooth HCIs (max %i).\n", MAX_NICS);
+ return -1;
+ }
+
+ hci = hci_init(str);
+ if (!hci)
+ return -1;
+
+ bdaddr.b[0] = 0x52;
+ bdaddr.b[1] = 0x54;
+ bdaddr.b[2] = 0x00;
+ bdaddr.b[3] = 0x12;
+ bdaddr.b[4] = 0x34;
+ bdaddr.b[5] = 0x56 + nb_hcis;
+ hci->bdaddr_set(hci, bdaddr.b);
+
+ hci_table[nb_hcis++] = hci;
+
+ return 0;
+}
+
+static void bt_vhci_add(int vlan_id)
+{
+ struct bt_scatternet_s *vlan = qemu_find_bt_vlan(vlan_id);
+
+ if (!vlan->slave)
+ fprintf(stderr, "qemu: warning: adding a VHCI to "
+ "an empty scatternet %i\n", vlan_id);
+
+ bt_vhci_init(bt_new_hci(vlan));
+}
+
+static struct bt_device_s *bt_device_add(const char *opt)
+{
+ struct bt_scatternet_s *vlan;
+ int vlan_id = 0;
+ char *endp = strchr(opt, ':');
+ int len = (endp ? endp - opt : strlen(opt)) + 1;
+ char devname[10];
+
+ pstrcpy(devname, MIN(sizeof(devname), len), opt);
+
+ if (endp) {
+ vlan_id = strtol(endp + 1, &endp, 0);
+ if (*endp) {
+ fprintf(stderr, "qemu: unrecognised bluetooth vlan Id\n");
+ return 0;
+ }
+ }
+
+ vlan = qemu_find_bt_vlan(vlan_id);
+
+ if (!vlan->slave)
+ fprintf(stderr, "qemu: warning: adding a slave device to "
+ "an empty scatternet %i\n", vlan_id);
+
+ if (!strcmp(devname, "keyboard"))
+ return bt_keyboard_init(vlan);
+
+ fprintf(stderr, "qemu: unsupported bluetooth device `%s'\n", opt);
+ return 0;
+}
+
/***********************************************************/
/* QEMU Block devices */
@@ -5864,6 +5963,9 @@ static int usb_device_add(const char *devname)
return -1;
nd_table[nic].model = "usb";
dev = usb_net_init(&nd_table[nic]);
+ } else if (!strcmp(devname, "bt") || strstart(devname, "bt:", &p)) {
+ dev = usb_bt_init(devname[2] ? hci_init(p) :
+ bt_new_hci(qemu_find_bt_vlan(0)));
} else {
return -1;
}
@@ -7791,6 +7893,13 @@ static void help(int exitcode)
"-net none use it alone to have zero network devices; if no -net option\n"
" is provided, the default is '-net nic -net user'\n"
"\n"
+ "-bt null Dumb bluetooth HCI - doesn't respond to commands\n"
+ "-bt host[:id] Use host's HCI with the given name\n"
+ "-bt hci[,vlan=n]Emulate a standard HCI in virtual scatternet 'n'\n"
+ "-vhci n Add host computer to virtual scatternet 'n' using VHCI\n"
+ "-btdevice dev[,vlan=n]\n"
+ " Emulate a bluetooth device 'dev' in scatternet 'n'\n"
+ "\n"
#ifdef CONFIG_SLIRP
"-tftp dir allow tftp access to files in dir [-net user]\n"
"-bootp file advertise file in BOOTP replies\n"
@@ -7899,6 +8008,9 @@ enum {
QEMU_OPTION_bootp,
QEMU_OPTION_smb,
QEMU_OPTION_redir,
+ QEMU_OPTION_bt,
+ QEMU_OPTION_btdevice,
+ QEMU_OPTION_vhci,
QEMU_OPTION_kernel,
QEMU_OPTION_append,
@@ -7996,6 +8108,9 @@ const QEMUOption qemu_options[] = {
#endif
{ "redir", HAS_ARG, QEMU_OPTION_redir },
#endif
+ { "bt", HAS_ARG, QEMU_OPTION_bt },
+ { "btdevice", HAS_ARG, QEMU_OPTION_btdevice },
+ { "vhci", HAS_ARG, QEMU_OPTION_vhci },
{ "kernel", HAS_ARG, QEMU_OPTION_kernel },
{ "append", HAS_ARG, QEMU_OPTION_append },
@@ -8333,6 +8448,12 @@ int main(int argc, char **argv)
int cyls, heads, secs, translation;
const char *net_clients[MAX_NET_CLIENTS];
int nb_net_clients;
+ const char *bt_opts[MAX_NET_CLIENTS];
+ int nb_bt_opts;
+ int vhci_opts[MAX_NET_CLIENTS];
+ int nb_vhci_opts;
+ const char *btdevice_opts[MAX_NET_CLIENTS];
+ int nb_btdevice_opts;
int hda_index;
int optind;
const char *r, *optarg;
@@ -8415,6 +8536,9 @@ int main(int argc, char **argv)
usb_devices_index = 0;
nb_net_clients = 0;
+ nb_bt_opts = 0;
+ nb_vhci_opts = 0;
+ nb_btdevice_opts = 0;
nb_drives = 0;
nb_drives_opt = 0;
hda_index = -1;
@@ -8649,6 +8773,36 @@ int main(int argc, char **argv)
net_slirp_redir(optarg);
break;
#endif
+ case QEMU_OPTION_bt:
+ if (nb_bt_opts >= MAX_NET_CLIENTS) {
+ fprintf(stderr, "qemu: too many bluetooth devices\n");
+ exit(1);
+ }
+ bt_opts[nb_bt_opts++] = optarg;
+ break;
+ case QEMU_OPTION_vhci:
+ {
+ char *endp;
+ int vlan = strtol(optarg, &endp, 0);
+
+ if (*endp) {
+ fprintf(stderr, "qemu: bad scatternet '%s'\n", optarg);
+ exit(1);
+ }
+ if (nb_vhci_opts >= MAX_NET_CLIENTS) {
+ fprintf(stderr, "qemu: too many VHCI HCIs\n");
+ exit(1);
+ }
+ vhci_opts[nb_vhci_opts++] = vlan;
+ }
+ break;
+ case QEMU_OPTION_btdevice:
+ if (nb_btdevice_opts >= MAX_NET_CLIENTS) {
+ fprintf(stderr, "qemu: too many bluetooth slaves\n");
+ exit(1);
+ }
+ btdevice_opts[nb_btdevice_opts++] = optarg;
+ break;
#ifdef HAS_AUDIO
case QEMU_OPTION_audio_help:
AUD_help ();
@@ -9118,6 +9272,16 @@ int main(int argc, char **argv)
}
#endif
+ /* init the bluetooth world */
+ for (i = 0; i < nb_bt_opts; i++)
+ if (bt_hci_parse(bt_opts[i]))
+ exit(1);
+ for (i = 0; i < nb_vhci_opts; i++)
+ bt_vhci_add(vhci_opts[i]);
+ for (i = 0; i < nb_btdevice_opts; i++)
+ if (!bt_device_add(btdevice_opts[i]))
+ exit(1);
+
/* init the memory */
phys_ram_size = machine->ram_require & ~RAMSIZE_FIXED;
--
1.5.3.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Bluetooth options
2008-09-29 1:27 [Qemu-devel] Bluetooth options andrzej zaborowski
@ 2008-09-29 10:54 ` Paul Brook
2008-10-11 11:18 ` andrzej zaborowski
0 siblings, 1 reply; 5+ messages in thread
From: Paul Brook @ 2008-09-29 10:54 UTC (permalink / raw)
To: qemu-devel
On Monday 29 September 2008, andrzej zaborowski wrote:
> Hi,
> I added code to emulate various bluetooth hardware but I didn't add
> any user interface to set it up or tweak. The attached patch adds
> command line switches for doind that but it's not very pretty, any
> suggestions to change it will be appreciated.
Do we really need 3 different options? Can't everything be done with a
single -bt option, like it is with -net?
I'd kinda expect serial bluetooth dongles to be added the same way as USB
ones, i.e. via -serial options.
Paul
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Bluetooth options
2008-09-29 10:54 ` Paul Brook
@ 2008-10-11 11:18 ` andrzej zaborowski
2008-10-11 12:06 ` Paul Brook
0 siblings, 1 reply; 5+ messages in thread
From: andrzej zaborowski @ 2008-10-11 11:18 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]
2008/9/29 Paul Brook <paul@codesourcery.com>:
> On Monday 29 September 2008, andrzej zaborowski wrote:
>> Hi,
>> I added code to emulate various bluetooth hardware but I didn't add
>> any user interface to set it up or tweak. The attached patch adds
>> command line switches for doind that but it's not very pretty, any
>> suggestions to change it will be appreciated.
>
> 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.
The syntax is now:
-bt hci,null
-bt hci,host[:id]
-bt hci[,vlan=N]
-bt vhci[,vlan=N]
-bt device:dev[,vlan=N]
>
> 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.
Regards
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-commandline-options-to-make-use-of-bluetooth-2.patch --]
[-- Type: text/x-patch; name=0001-Add-commandline-options-to-make-use-of-bluetooth-2.patch, Size: 7398 bytes --]
diff --git a/vl.c b/vl.c
index e8410a8..395fe46 100644
--- a/vl.c
+++ b/vl.c
@@ -163,6 +163,9 @@
/* Max number of USB devices that can be specified on the commandline. */
#define MAX_USB_CMDLINE 8
+/* Max number of bluetooth switches on the commandline. */
+#define MAX_BT_CMDLINE 10
+
/* XXX: use a two level table to limit memory usage */
#define MAX_IOPORTS 65536
@@ -5409,6 +5412,144 @@ struct HCIInfo *qemu_next_hci(void)
return hci_table[cur_hci++];
}
+static struct HCIInfo *hci_init(const char *str)
+{
+ char *endp;
+ struct bt_scatternet_s *vlan = 0;
+
+ if (!strcmp(str, "null"))
+ /* null */
+ return &null_hci;
+ else if (!strncmp(str, "host", 4) && (str[4] == '\0' || str[4] == ':'))
+ /* host[:hciN] */
+ return bt_host_hci(str[4] ? str + 5 : "hci0");
+ else if (!strncmp(str, "hci", 3)) {
+ /* hci[,vlan=n] */
+ if (str[3]) {
+ if (!strncmp(str + 3, ",vlan=", 6)) {
+ vlan = qemu_find_bt_vlan(strtol(str + 9, &endp, 0));
+ if (*endp)
+ vlan = 0;
+ }
+ } else
+ vlan = qemu_find_bt_vlan(0);
+ if (vlan)
+ return bt_new_hci(vlan);
+ }
+
+ fprintf(stderr, "qemu: Unknown bluetooth HCI `%s'.\n", str);
+
+ return 0;
+}
+
+static int bt_hci_parse(const char *str)
+{
+ struct HCIInfo *hci;
+ bdaddr_t bdaddr;
+
+ if (nb_hcis >= MAX_NICS) {
+ fprintf(stderr, "qemu: Too many bluetooth HCIs (max %i).\n", MAX_NICS);
+ return -1;
+ }
+
+ hci = hci_init(str);
+ if (!hci)
+ return -1;
+
+ bdaddr.b[0] = 0x52;
+ bdaddr.b[1] = 0x54;
+ bdaddr.b[2] = 0x00;
+ bdaddr.b[3] = 0x12;
+ bdaddr.b[4] = 0x34;
+ bdaddr.b[5] = 0x56 + nb_hcis;
+ hci->bdaddr_set(hci, bdaddr.b);
+
+ hci_table[nb_hcis++] = hci;
+
+ return 0;
+}
+
+static void bt_vhci_add(int vlan_id)
+{
+ struct bt_scatternet_s *vlan = qemu_find_bt_vlan(vlan_id);
+
+ if (!vlan->slave)
+ fprintf(stderr, "qemu: warning: adding a VHCI to "
+ "an empty scatternet %i\n", vlan_id);
+
+ bt_vhci_init(bt_new_hci(vlan));
+}
+
+static struct bt_device_s *bt_device_add(const char *opt)
+{
+ struct bt_scatternet_s *vlan;
+ int vlan_id = 0;
+ char *endp = strstr(opt, ",vlan=");
+ int len = (endp ? endp - opt : strlen(opt)) + 1;
+ char devname[10];
+
+ pstrcpy(devname, MIN(sizeof(devname), len), opt);
+
+ if (endp) {
+ vlan_id = strtol(endp + 6, &endp, 0);
+ if (*endp) {
+ fprintf(stderr, "qemu: unrecognised bluetooth vlan Id\n");
+ return 0;
+ }
+ }
+
+ vlan = qemu_find_bt_vlan(vlan_id);
+
+ if (!vlan->slave)
+ fprintf(stderr, "qemu: warning: adding a slave device to "
+ "an empty scatternet %i\n", vlan_id);
+
+ if (!strcmp(devname, "keyboard"))
+ return bt_keyboard_init(vlan);
+
+ fprintf(stderr, "qemu: unsupported bluetooth device `%s'\n", devname);
+ return 0;
+}
+
+static int bt_parse(const char *opt)
+{
+ const char *endp, *p;
+ int vlan;
+
+ if (strstart(opt, "hci", &endp)) {
+ if (!*endp || *endp == ',') {
+ if (*endp)
+ if (!strstart(endp, ",vlan=", 0))
+ opt = endp + 1;
+
+ return bt_hci_parse(opt);
+ }
+ } else if (strstart(opt, "vhci", &endp)) {
+ if (!*endp || *endp == ',') {
+ if (*endp) {
+ if (strstart(endp, ",vlan=", &p)) {
+ vlan = strtol(p, (char **) &endp, 0);
+ if (*endp) {
+ fprintf(stderr, "qemu: bad scatternet '%s'\n", p);
+ return 1;
+ }
+ } else {
+ fprintf(stderr, "qemu: bad parameter '%s'\n", endp + 1);
+ return 1;
+ }
+ } else
+ vlan = 0;
+
+ bt_vhci_add(vlan);
+ return 0;
+ }
+ } else if (strstart(opt, "device:", &endp))
+ return !bt_device_add(endp);
+
+ fprintf(stderr, "qemu: bad bluetooth parameter '%s'\n", opt);
+ return 1;
+}
+
/***********************************************************/
/* QEMU Block devices */
@@ -5859,6 +6000,9 @@ static int usb_device_add(const char *devname)
return -1;
nd_table[nic].model = "usb";
dev = usb_net_init(&nd_table[nic]);
+ } else if (!strcmp(devname, "bt") || strstart(devname, "bt:", &p)) {
+ dev = usb_bt_init(devname[2] ? hci_init(p) :
+ bt_new_hci(qemu_find_bt_vlan(0)));
} else {
return -1;
}
@@ -8146,6 +8290,16 @@ static void help(int exitcode)
"-net none use it alone to have zero network devices; if no -net option\n"
" is provided, the default is '-net nic -net user'\n"
"\n"
+ "-bt hci,null Dumb bluetooth HCI - doesn't respond to commands\n"
+ "-bt hci,host[:id]\n"
+ " Use host's HCI with the given name\n"
+ "-bt hci[,vlan=n]\n"
+ " Emulate a standard HCI in virtual scatternet 'n'\n"
+ "-bt vhci[,vlan=n]\n"
+ " Add host computer to virtual scatternet 'n' using VHCI\n"
+ "-bt device:dev[,vlan=n]\n"
+ " Emulate a bluetooth device 'dev' in scatternet 'n'\n"
+ "\n"
#ifdef CONFIG_SLIRP
"-tftp dir allow tftp access to files in dir [-net user]\n"
"-bootp file advertise file in BOOTP replies\n"
@@ -8254,6 +8408,7 @@ enum {
QEMU_OPTION_bootp,
QEMU_OPTION_smb,
QEMU_OPTION_redir,
+ QEMU_OPTION_bt,
QEMU_OPTION_kernel,
QEMU_OPTION_append,
@@ -8351,6 +8506,7 @@ static const QEMUOption qemu_options[] = {
#endif
{ "redir", HAS_ARG, QEMU_OPTION_redir },
#endif
+ { "bt", HAS_ARG, QEMU_OPTION_bt },
{ "kernel", HAS_ARG, QEMU_OPTION_kernel },
{ "append", HAS_ARG, QEMU_OPTION_append },
@@ -8688,6 +8844,8 @@ int main(int argc, char **argv)
int cyls, heads, secs, translation;
const char *net_clients[MAX_NET_CLIENTS];
int nb_net_clients;
+ const char *bt_opts[MAX_BT_CMDLINE];
+ int nb_bt_opts;
int hda_index;
int optind;
const char *r, *optarg;
@@ -8771,6 +8929,7 @@ int main(int argc, char **argv)
usb_devices_index = 0;
nb_net_clients = 0;
+ nb_bt_opts = 0;
nb_drives = 0;
nb_drives_opt = 0;
hda_index = -1;
@@ -9006,6 +9165,13 @@ int main(int argc, char **argv)
net_slirp_redir(optarg);
break;
#endif
+ case QEMU_OPTION_bt:
+ if (nb_bt_opts >= MAX_BT_CMDLINE) {
+ fprintf(stderr, "qemu: too many bluetooth options\n");
+ exit(1);
+ }
+ bt_opts[nb_bt_opts++] = optarg;
+ break;
#ifdef HAS_AUDIO
case QEMU_OPTION_audio_help:
AUD_help ();
@@ -9482,6 +9648,11 @@ int main(int argc, char **argv)
}
#endif
+ /* init the bluetooth world */
+ for (i = 0; i < nb_bt_opts; i++)
+ if (bt_parse(bt_opts[i]))
+ exit(1);
+
/* init the memory */
phys_ram_size = machine->ram_require & ~RAMSIZE_FIXED;
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Bluetooth options
2008-10-11 11:18 ` andrzej zaborowski
@ 2008-10-11 12:06 ` Paul Brook
2008-10-11 12:51 ` andrzej zaborowski
0 siblings, 1 reply; 5+ messages in thread
From: Paul Brook @ 2008-10-11 12:06 UTC (permalink / raw)
To: qemu-devel
> > 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] Bluetooth options
2008-10-11 12:06 ` Paul Brook
@ 2008-10-11 12:51 ` andrzej zaborowski
0 siblings, 0 replies; 5+ messages in thread
From: andrzej zaborowski @ 2008-10-11 12:51 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel
2008/10/11 Paul Brook <paul@codesourcery.com>:
>> > 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-10-11 12:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-29 1:27 [Qemu-devel] Bluetooth options andrzej zaborowski
2008-09-29 10:54 ` Paul Brook
2008-10-11 11:18 ` andrzej zaborowski
2008-10-11 12:06 ` Paul Brook
2008-10-11 12:51 ` andrzej zaborowski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).