summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJoão Paulo Rechi Vita <jprvita@openbossa.org>2012-03-02 19:58:45 -0300
committerJoão Paulo Rechi Vita <jprvita@openbossa.org>2012-03-02 19:58:45 -0300
commit695d33828d185da72c6cd420ec10c488eb01cd0a (patch)
treeebf46e3ac1292712760cfbdb94ebd1ce134faa26
parentabf9ab0fb7ef9a947ab453b0f03abe7379ec2c84 (diff)
downloadbluez-le-docs-695d33828d185da72c6cd420ec10c488eb01cd0a.tar.gz
bluez-le-docs-695d33828d185da72c6cd420ec10c488eb01cd0a.tar.xz
bluez-le-docs-695d33828d185da72c6cd420ec10c488eb01cd0a.zip
bluez: latex and language fixes
-rw-r--r--bluez.tex66
1 files changed, 33 insertions, 33 deletions
diff --git a/bluez.tex b/bluez.tex
index 2c39450..dad4ab2 100644
--- a/bluez.tex
+++ b/bluez.tex
@@ -52,7 +52,7 @@ and user-level tools. The kernel is responsible for managing the Bluetooth
hardware resources attached to the system handling manufacturer hooks, and
providing an interface to the userspace. bluetoothd is a root level daemon
responsible for providing a D-Bus interface to allow user applications to
-manage adapter, devices and services.
+manage adapters, devices, and services.
An overview of how these pieces fit together is depicted on Figure
\ref{fig:bluez-architecture}
@@ -98,33 +98,33 @@ manage local adapters and control device creation procedure.
\subsection{core}
BlueZ core provides the abstraction to manage adapters, devices, services
-discovery, and security. Service(Profiles) plugins are implemented on the
+discovery, and security. Service (Profiles) plugins are implemented on the
top of it. The major entities of the core are: adapter, device, sdp, agent
for authorization and pairing, and GAttrib.
In BlueZ, create a device means to get from the remote the services
-information, and to pair with it(CreatePairedDevice). BR/EDR and Bluetooth Low
+information, and to pair with it (CreatePairedDevice). BR/EDR and Bluetooth Low
Energy uses the same API to discover devices and to manage pairing, the user
does not need to know the adapters capabilities. The abstraction is implemented
in the kernel and {\em bluetoothd} daemon.
-Services plugins are in general device driver(s) for a specific Bluetooth
+Service plugins are in general device driver(s) for a specific Bluetooth
service. The design is based on the kernel device drivers: when the device
is created, plugins are probed based on the supported UUIDs. It is analogous
to kernel device driver ids. When a remote device exposes more than one
service, each plugin gets a reference to the device {\em object}.
-Standard device discovery takes 10.12 seconds(defined in the Bluetooth GAP
+Standard device discovery takes 10.12 seconds (defined in the Bluetooth GAP
specification). For dual mode controllers, the GAP specification recomends
a Interleaved Discovery Procedure: 5.12s inquiring followed by 5.12s scanning.
In BlueZ, the discovery procedure works over both interfaces: Management, and
standard HCI command interface. The abstraction is implemented by the
{\em adapter\_ops} plugin, which hides from the {\em bluetoothd} upper layer
-the kernel interface in use. Management Interface has higer priority, if it is
+the kernel interface in use. Management Interface has higer priority: if it is
enabled in the kernel the default interface will be set to Management.
-Name resolution is part of the device discovery procedure for BlueZ, since
-there isn't restrictions prohibiting to switch the order of the Interleave
+Name resolution is part of the device discovery procedure for BlueZ. Since
+there aren't restrictions prohibiting to switch the order of the Interleave
Discovery, BlueZ executes LE scanning before inquiry to reduce the discovery
state machine complexity.
@@ -135,10 +135,10 @@ method setup requires Management Interface.
\subsection{libs}
BlueZ libs (a.k.a libbluetooth) is a development library which provides
-common functions and structures that can be used by Linux 'c' programmers.
+common functions and structures that can be used by Linux C programmers.
libbluetooth usage is not encouraged, nowadays bluetoothd exposes friendly
-IPC methods(over D-Bus) which covers the most common operations. Use
+IPC methods (over D-Bus) which covers the most common operations. Usage of
libbluetooth can be also introduce potential race conditions with bluetoothd
operations.
@@ -153,12 +153,12 @@ source code repository.
%\subsubsection{network}
\subsection{Management Interface}
-The Management Interface ("mgmtops" plugin) is a new interface for userspace
-side in BlueZ to communicate with the kernel side. Its purpose is to remove the
-raw HCI sockets from userspace and replace the deprecated "hciops" plugin (old
+The Management Interface ({\em mgmtops} plugin) is a new interface for the
+userspace to communicate with the kernel. Its purpose is to remove the raw
+HCI sockets from userspace and replace the deprecated {\em hciops} plugin (old
interface).
-Some advantages of mgmtops plugin in comparison with hciops plugin:
+Some advantages of {\em mgmtops} plugin in comparison with {\em hciops} plugin:
\begin{itemize}
\item Command queues and synchronization: All HCI traffic is handled by the kernel,
@@ -172,17 +172,17 @@ Some advantages of mgmtops plugin in comparison with hciops plugin:
all HCI traffic since first moment which adapter is plugged.
\end{itemize}
-There is a layer called "adapter operations" ({\em adapter\_ops} struct in
-{\em src/adapter.c}) that describes how to communicate with kernel side. For the
-management interface, this layer is implemented in {\em plugins/mgmtops.c}.
+There is a layer called {\em adapter operations} (\verb|src/adapter.c|) that
+describes how to communicate with kernel side. For the management interface,
+this layer is implemented in \verb|plugins/mgmtops.c|.
-The mgmt interface is enabled by default on recent Linux kernel tree. It is
+The MGMT interface is enabled by default on recent Linux kernel tree. It is
still necessary to enable the LE support, so it can be used with LE devices.
There are two ways to enable LE support:
\begin{enumerate}
\item If the Bluetooth subsystem is compiled as module, it can be enabled while
- loading the "bluetooth" module:
+ loading the {\em bluetooth} module:
\begin{verbatim}
$ sudo modprobe bluetooth enable_le
@@ -202,7 +202,7 @@ To verify that LE support is enabled, use:
$ cat /sys/module/bluetooth/parameters/enable_le
\end{verbatim}
-If will show "Y" if LE support is enabled.
+It will show \verb|Y| if LE support is enabled.
BlueZ will use mgmtops automatically instead of hciops if it detects that the
kernel has support for mgmt.
@@ -220,11 +220,11 @@ The Security Manager (SM) defines the protocol and behavior to manage pairing
and key distribution, authentication and encryption between LE devices.
The device in the master role shall initiate the Security procedures and the
-device in the slave role shall responding. The slave will send to the master a
+device in the slave role shall respond. The slave will send to the master a
Security Request command and it may encrypt the link or reject de request.
In the BlueZ, only the minimum from Security Manager was implemented.
-Currently, only the method "Just Works" is running (method provides no
+Currently, only the method {\em Just Works} is supported (method provides no
protection against eavesdroppers or man in the middle attacks during the
pairing process).
@@ -232,19 +232,19 @@ In BlueZ API, there are two methods to connect and/or pair with devices,
{\em CreateDevice} and {\em CreatePairedDevice}.
{\em CreateDevice} creates a new object path for a remote device and
-connect to device. So it will retrieve all SDP records. Note that this
+connects to the device. It will retrieve all SDP records. Note that this
method will fail if a path for the remote device already exists.
{\em CreatePairedDevice} shares some characteristics with {\em CreateDevice}.
-It creates object path (if not exists), connect to remote device and then
-initiate the pairing. It will fails if the pairing already exists.
+It creates object path (if not exists), connects to the remote device and then
+initiates the pairing. It will fail if the pairing already exists.
Consequently there is the option of create a device connection with
{\em CreateDevice} and pair after with {\em CreatePairedDevice}.
-Addtionally, we can increasing security level after connection setting
-\verb|BT_IO_OPT_SEC_LEVEL| using {\em bt\_io\_set()} function. After that, a
-security request is sent to the master and security precess is initiated.
+Additionally, we can increase the connection security with the \verb|bt_io_set()| function,
+setting the level to \verb|BT_IO_OPT_SEC_LEVEL|. After that, a
+security request is sent to the master and the security process is initiated.
\subsection{Services over GATT}
@@ -289,7 +289,7 @@ need to hold at least one reference to a GAttrib for as long as the connection
is necessary, and drop this reference when the connection is no longer needed.
It is possible to run custom code when a connection is established or
-terminated by using "ATT connection callbacks" (or attio callbacks, for short).
+terminated by using {\em ATT connection callbacks} (or attio callbacks, for short).
These callbacks should be registered whenever the GATT profile has intent to
communicate with a remote device. When implementing attio callbacks, it is
important to make sure there is a valid reference to the current GAttrib as
@@ -360,13 +360,13 @@ applies to the client side: Find Me Locator and Proximity Monitor share the
same D-Bus interface.
Note that even if a peer device only supports one profile (either Proximity or
-Find Me), the API will still work at least for the shared "Immediate Alert"
+Find Me), the API will still work at least for the shared {\em Immediate Alert}
functionality.
\subsubsection{Thermometer}
-Profile used to interact with data gathered from thermal sensors. There are two
-roles in this profile: {\em Thermometer} and {\em Collector}.
+This profile is used to interact with data gathered from temperature sensors.
+There are two roles in this profile: {\em Thermometer} and {\em Collector}.
For devices that support {\em Thermometer Role}, thermal data is stored and
exposed to {\em Collector}. It is mandatory to have {\em Device Information}
@@ -407,7 +407,7 @@ implement the \verb|MeasurementReceived| method with a dict parameter:
The \verb|Time| value is expressed in seconds since epoch.
The temperature value is represented by \verb|(mantissa) x (10**exponent)|.
-\subsubsection{Time}
+%\subsubsection{Time}
\section{Contact channels}