汝の名はBlueZ - (7)

あらすじ

hiro99ma blog: 汝の名はBlueZ - (1) : BlueZはあまり情報がない、ということを書いただけ
hiro99ma blog: 汝の名はBlueZ - (2) : なんでBlueZをやろうと思ったか、ということを書いただけ
hiro99ma blog: 汝の名はBlueZ - (3) : Raspberry PiでBLEのスキャンをするサンプルを動かした
hiro99ma blog: 汝の名はBlueZ - (4) : スキャンするサンプルの概要
hiro99ma blog: 汝の名はBlueZ - (5) : Raspberry PiのBlueZを最新にしようとしたことを書いただけ
hiro99ma blog: 汝の名はBlueZ - (6) : hcitoolとgatttoolに特に連携は無いことがわかった

今回は、gatttoolのconnectについて調べようと思っていたのだが、そう簡単には進まない。
gatttoolはいくつかライブラリを組み合わせて作られているのだが、その辺を知らないので読み進まないのだ。
なので、まずは周辺のことから調べていく。

---

まずMakefileから。

if READLINE
noinst_PROGRAMS += attrib/gatttool \
            tools/obex-client-tool tools/obex-server-tool \
            tools/bluetooth-player tools/obexctl
attrib_gatttool_SOURCES = attrib/gatttool.c attrib/att.c attrib/gatt.c \
                attrib/gattrib.c btio/btio.c \
                attrib/gatttool.h attrib/interactive.c \
                attrib/utils.c src/log.c client/display.c \
                client/display.h
attrib_gatttool_LDADD = lib/libbluetooth-internal.la \
            src/libshared-glib.la @GLIB_LIBS@ -lreadline
・・・(以下略)

まず、READLINEが定義されているときしかビルドされない。
そして、noinst_PROGRAMSとあるから、インストール対象外になってるのだろう。

リンクしているのは、自分の以外ではGLIB_LIBSと-lreadline。

ソースファイルは、こう。

• attrib/gatttool.c
• attrib/att.c
• attrib/gatt.c
• attrib/gattrib.c
• attrib/interactive.c
• attrib/utils.c
• btio/btio.c
• src/log.c
• client/display.c

gatttoolでconnectするところだけだとinteractive.cで、gatttoolのmainがgatttool.cにある。
困ったことにatt.cはプレフィクスが不定なのだが、gatt.cやgattlib.c、utils.cはプレフィクスがついているから、そこまで見分けるのは大変ではないのかもしれない。btio.cもプレフィクスがついてるし。

log.cはデバッグマクロだけなのでよいとして、display.cだ。
これのプレフィクスが「rl_」になっている。
rlが付くのは、どうもReadLineライブラリ関係のようで、標準入力をさばいてくれるライブラリのようだ。
読みやすかったのは、こちらのサイト。
GNU Readlineを使ってみる

---

interactive.cで、プロンプトの出力はget_prompt()が行っている。
入力文字列の解析は、parse_line()が行っているようだ。
これらをrl_callback_handler_install()で登録しているから、入力が完了(Enter押したとき)に

• parse_line()
• 入力コマンドに応じた処理
• get_prompt()

の順で動いているようだ。

connectしたとき、入力を確定させてから出力が終わるまでにしばらく時間がかかったので、同期でconnect処理をしているはず。
connectに対応する処理はcmd_connect()で、そこでgatt_connect()を呼んでいる。
これが接続要求ということで間違いないだろう。
その戻り値はGIOChannel*型。だから、BlueZのgatt系APIを使うのなら、GLibは使うことが前提になるようだ。
ただ、gatt_connect()はutils.cの関数で、そのヘッダファイルはgatttool.hにある(utils.cには独自のヘッダファイルがない)。
そういう意味では、gatt_connect()はBlueZの一部ではないと割り切って、自前で何かしてしまえるのかもしれない。

けど、btioがglib.hをincludeしてるので、結局はGLibに頼るのが正解のような気がしている。

---

そこで気になるのが、D-Busだ。
D-BusはAndroidのsystemとかが使ってるなー、というイメージしかなかったのだが、BlueZでも使われている。
BlueZ » Blog Archive » BlueZ 5 API introduction and porting guide

そもそもD-Busは何かというと、オーバーヘッドが少ないプロセス間通信(IPC)だそうな。
D-Bus Specification

こちらを読むと、BlueZはデーモンとGUIアプレットがD-BUS I/Fで通信するようになっている。
Bluetoothのはなし(4)｜Wireless・のおと｜サイレックス・テクノロジー株式会社

じゃあCUIはどうなってるかというと、図を見るとlibbluetooth.soがドライバをたたいているようだ。
なので、CUIで使う分にはD-Busは気にしなくてよいというか、libbluetoothを使うのであればD-Busは気にしなくてよいということになるだろう。

---

なんというか・・・思っていたよりも大ごとなので、尻込みし始めている。
gatttoolを「interactive」で動かすオプションがあるということは、そうじゃない動作が普通ということになる。
bluez/testの中を見ても、pythonで書かれたコードばかりだ。
C/C++でごりごり書くのを調べるより、pythonを覚えてサンプルをいじった方が早いのかも。
うぅ・・・。