aboutsummaryrefslogtreecommitdiff
path: root/qemu-options.hx
diff options
context:
space:
mode:
authorThomas Huth <thuth@redhat.com>2019-11-20 10:10:13 +0100
committerThomas Huth <thuth@redhat.com>2019-12-17 09:01:14 +0100
commit1d4ffe8dc77cbc9aafe8bcf514ca0e43f85aaae3 (patch)
tree7f4ae35a4b2b3aa47c889478fab9c95562fa67f1 /qemu-options.hx
parent43d68d0a94ef13058f6479b3dd490169a9a62966 (diff)
Remove the core bluetooth code
It's been deprecated since QEMU v3.1. We've explicitly asked in the deprecation message that people should speak up on qemu-devel in case they are still actively using the bluetooth part of QEMU, but nobody ever replied that they are really still using it. I've tried it on my own to use this bluetooth subsystem for one of my guests, but I was also not able to get it running anymore: When I was trying to pass-through a real bluetooth device, either the guest did not see the device at all, or the guest crashed. Even worse for the emulated device: When running qemu-system-x86_64 -bt device:keyboard QEMU crashes once you hit a key. So it seems like the bluetooth stack is not only neglected, it is completely bitrotten, as far as I can tell. The only attention that this code got during the past years were some CVEs that have been spotted there. So this code is a burden for the developers, without any real benefit anymore. Time to remove it. Note: hw/bt/Kconfig only gets cleared but not removed here yet. Otherwise there is a problem with the *-softmmu/config-devices.mak.d dependency files - they still contain a reference to this file which gets evaluated first on some build hosts, before the file gets properly recreated. To avoid breaking these builders, we still need the file around for some time. It will get removed in a couple of weeks instead. Message-Id: <20191120091014.16883-4-thuth@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Diffstat (limited to 'qemu-options.hx')
-rw-r--r--qemu-options.hx79
1 files changed, 0 insertions, 79 deletions
diff --git a/qemu-options.hx b/qemu-options.hx
index 3ff8c4e07a..c63e794b64 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3115,85 +3115,6 @@ STEXI
ETEXI
DEFHEADING()
-DEFHEADING(Bluetooth(R) options:)
-STEXI
-@table @option
-ETEXI
-
-DEF("bt", HAS_ARG, QEMU_OPTION_bt, \
- "-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",
- QEMU_ARCH_ALL)
-STEXI
-@item -bt hci[...]
-@findex -bt
-Defines the function of the corresponding Bluetooth HCI. -bt options
-are matched with the HCIs present in the chosen machine type. For
-example when emulating a machine with only one HCI built into it, only
-the first @code{-bt hci[...]} option is valid and defines the HCI's
-logic. The Transport Layer is decided by the machine type. Currently
-the machines @code{n800} and @code{n810} have one HCI and all other
-machines have none.
-
-Note: This option and the whole bluetooth subsystem is considered as deprecated.
-If you still use it, please send a mail to @email{qemu-devel@@nongnu.org} where
-you describe your usecase.
-
-@anchor{bt-hcis}
-The following three types are recognized:
-
-@table @option
-@item -bt hci,null
-(default) The corresponding Bluetooth HCI assumes no internal logic
-and will not respond to any HCI commands or emit events.
-
-@item -bt hci,host[:@var{id}]
-(@code{bluez} only) The corresponding HCI passes commands / events
-to / from the physical HCI identified by the name @var{id} (default:
-@code{hci0}) on the computer running QEMU. Only available on @code{bluez}
-capable systems like Linux.
-
-@item -bt hci[,vlan=@var{n}]
-Add a virtual, standard HCI that will participate in the Bluetooth
-scatternet @var{n} (default @code{0}). Similarly to @option{-net}
-VLANs, devices inside a bluetooth network @var{n} can only communicate
-with other devices in the same network (scatternet).
-@end table
-
-@item -bt vhci[,vlan=@var{n}]
-(Linux-host only) Create a HCI in scatternet @var{n} (default 0) attached
-to the host bluetooth stack instead of to the emulated target. This
-allows the host and target machines to participate in a common scatternet
-and communicate. Requires the Linux @code{vhci} driver installed. Can
-be used as following:
-
-@example
-@value{qemu_system} [...OPTIONS...] -bt hci,vlan=5 -bt vhci,vlan=5
-@end example
-
-@item -bt device:@var{dev}[,vlan=@var{n}]
-Emulate a bluetooth device @var{dev} and place it in network @var{n}
-(default @code{0}). QEMU can only emulate one type of bluetooth devices
-currently:
-
-@table @option
-@item keyboard
-Virtual wireless keyboard implementing the HIDP bluetooth profile.
-@end table
-ETEXI
-
-STEXI
-@end table
-ETEXI
-DEFHEADING()
-
#ifdef CONFIG_TPM
DEFHEADING(TPM device options:)