This patch refactors the pairing code in hciops and the core daemon to
better match the management interface. Particularly all logic regarding
IO capabilities and authentication requirements are moved into hciops.c.
The patch is quite big because there are a lot of cross-dependencies
which makes it difficult to split the changes up into smaller chunks.
The important adapter_ops preparations for the management interface in
this patch are the create_bonding and cancel_bonding callbacks. Those
will be directly mapped to corresponding management commands.
There's no point to export connection handle details to the core daemon
since it will not be available in the management interface. Instead
track the handles inside hciops (managment interface will do this inside
the kernel).
This patch updates the class of device handling code to match the latest
management interface. A notable feature is that UUID to service class
mapping policy remains in user space with the help of the svc_hint
parameter of the add_uuid command. This is to make it easy to update the
mapping table when new profiles come along.
This patch adds support for the add_uuid and remove_uuid management
commands. The kernel uses them to track the list of UUIDs and
automatically set the service class bits as well as the EIR value
accordingly.
This patch implements support for the set_pairable managment command.
Due to the async nature of it a new btd_adapter_pairable_changed
function is added to the core daemon.
The management interface will have simple add_uuid and remove_uuid
methods so it makes sense to have the adapter_ops interface reflect
that. This patch removes the services_updated callback and replaces it
with add_uuid and remove_uuid callbacks.
The events, commands and responses to these modes are represented by
identical management messages. By having a unified struct for all of
them quite a lot of code can simplified and reused.
The current idea is to have a single set_powered management command
which for the switching on case would leave the controller in a
non-connectable, non-pairable and non-discoverable state.
There's no need for the core daemon to have special handling for debug
keys anymore as long as it tells adapter_ops if they are enabled or not
(new parameter added to adapter_ops->load_keys).
The management interface will enable storing link keys in runtime memory
in the kernel. This patch makes the adapter interface match this model
and adds storing of link keys into hciops.
This (rather big) patch refactors the way that adapters are initialized
and powered on/off. The purpose is to align the adapter_ops <-> core
daemon interface with how the management interface will behave.
The management interface will move class of device and extended inquiry
response handling to the kernel side so the same functionality needs to
be moved into hciops. These features are quite tightly coupled in
bluetoothd so splitting this into multiple patches would have been hard
(if not impossible). Thus this quite large single commit.
The read_mode and read_info commands are issued only once in the
beginning for each adapter so it doesn't make sense to have the
information fetching split across two different commands. Instead all
necessary info can be fetched through the read_info command.
In addition to blocking the mainloop hci_send_req changes the socket
filters which makes it unusable for the per-adapter HCI socket in
hciops.c. Using hci_send_cmd makes much more sense here.
Since the only thing the code does upon a write_ssp_mode_complete event
is issue a read_ssp_mode command it makes sense to have this internal to
hciops.
Several adapter initialization features will be handled by the new
management interface in the future, so move these from adapter.c into
hciops. This also gets rid of a couple of unnecessary adapter_ops
callbacks.
