Кто-нибудь может объяснить эту команду - PullRequest
0 голосов
/ 17 января 2012

Здесь я хочу кратко узнать о команде dbus-send

Я хочу знать, как мы можем использовать это и как эта команда автоматически вызывает функции других файлов c.

Здесь я привел один пример, который используется при сопряжении Bluetooth и отключении пар. объясните пожалуйста

dbus-send --system --print-reply --dest=org.bluez  $BT_ADAPTER org.bluez.Adapter.RemoveDevice objpath:$BT_ADAPTER/dev_$BD_ADDR_XX

Здесь BT_ADAPTER - это синий адаптер, например: /org/bluez/1536/hci0 BD_ADDR_XX - адрес Bluetooth: XX_XX_XX_XX_XX_XX

Здесь я знаю о параметрах --system --print-reply и всех других параметрах, но как он работает с исходными файлами, я не знаю.

Так что кто-нибудь, пожалуйста, может объяснить, как этот вызов команды и использовать функции из исходных файлов C.

1 Ответ

2 голосов
/ 17 января 2012

Вам нужно проверить документ dbus, и есть долгий путь.

http://www.freedesktop.org/wiki/IntroductionToDBus

Что именно вы хотите? Написание службы dbus или клиента?

Должны ли вы писать на C, потому что Python был бы гораздо лучшим выбором. http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html

============================

Сначала служба dbus подключается к dbus-daemon и запрашивает адрес службы (в вашем случае org.bluez). Затем он регистрирует разные интерфейсы на разных путях объекта, каждый интерфейс содержит некоторые вызовы / сигналы методов для пользователей.

В вашем случае:

  • Запущен процесс демона Dbus (dbus-daemon --system).

  • Запустился процесс демона Bluez и запросил у dbus-daemon адрес службы "org.bluez"

  • Процесс демона Bluez регистрирует некоторые интерфейсы в / org / bluez / {pid процесса} / {имя контроллера bluetooth} (проверьте исходный код bluez в каталоге doc)

  • Когда вы вызываете команду dbus-send, инструмент командной строки подключится к dbus-daemon, отправив адрес службы (-dest), путь к объекту (/ org / bluez / 1536 / hci0), имя интерфейса, метод, который вы вызываете ( org.bluez.Adapter.RemoveDevice) и параметры.

  • Dbus-демон повторно отправляет его в bluez

============================

Dbus-демон не получает адрес службы или вызовы методов. Это вы или клиентский процесс сообщают ему адрес службы и имена вызовов методов.

Затем демон DBus отправит целевому процессу службы пакет данных, содержащий obj-путь, имя интерфейса / метода и параметры в своем собственном формате (через файл локальных сокетов unix).

Затем целевой процесс обслуживания распаковывает пакет, получает путь к объекту, интерфейс и т. Д., Решает, что он должен делать. Это не выполняется автоматически, и вам нужно написать собственный код для его обработки (диспетчеризация методов или около того) или использовать некоторую библиотеку, например dbus-glib / gdbus.

============================

Я проверил исходный код Bluez-4.98. Для отправки метода используется gdbus.

Возьмем, к примеру, «CreateDevice».

в src / adapter.c, есть такая структура

static GDBusMethodTable adapter_methods[] = {
{ "GetProperties",  "", "a{sv}",get_properties      },
{ "SetProperty",    "sv",   "", set_property,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "RequestSession", "", "", request_session,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "ReleaseSession", "", "", release_session     },
{ "StartDiscovery", "", "", adapter_start_discovery },
{ "StopDiscovery",  "", "", adapter_stop_discovery,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "ListDevices",    "", "ao",   list_devices,
                    G_DBUS_METHOD_FLAG_DEPRECATED},
{ "CreateDevice",   "s",    "o",    create_device,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "CreatePairedDevice", "sos",  "o",    create_paired_device,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "CancelDeviceCreation","s",   "", cancel_device_creation,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "RemoveDevice",   "o",    "", remove_device,
                    G_DBUS_METHOD_FLAG_ASYNC},
{ "FindDevice",     "s",    "o",    find_device     },
{ "RegisterAgent",  "os",   "", register_agent      },
{ "UnregisterAgent",    "o",    "", unregister_agent    },
{ }
};

, что означает, что вызов метода CreateDevice в конечном итоге вызовет функцию create_device.

И в строке 2418

    if (!g_dbus_register_interface(conn, path, ADAPTER_INTERFACE,
                adapter_methods, adapter_signals, NULL,
                adapter, adapter_free)) {
    error("Adapter interface init failed on path %s", path);
    adapter_free(adapter);
    return NULL;
}

вы регистрируете интерфейс ADAPTER_INTERFACE ("org.bluez.Adapter") со всеми его методами и сигналами.

Тогда все базовые мониторы событий и диспетчеризация dbus будут обрабатываться gdbus (после подключения init dbus и обработки событий в src / main.c). Когда какой-то клиент вызывает org.bluez.Adapter.CreateDevice, он в конечном итоге попадает в функцию create_device в строке 1468 src / adapter.c.

static DBusMessage *create_device(DBusConnection *conn,
                DBusMessage *msg, void *data)
{
struct btd_adapter *adapter = data;
struct btd_device *device;
const gchar *address;
DBusMessage *reply;
int err;

if (dbus_message_get_args(msg, NULL, DBUS_TYPE_STRING, &address,
                    DBUS_TYPE_INVALID) == FALSE)
    return btd_error_invalid_args(msg);

if (check_address(address) < 0)
    return btd_error_invalid_args(msg);

if (!adapter->up)
    return btd_error_not_ready(msg);

if (adapter_find_device(adapter, address))
    return btd_error_already_exists(msg);

DBG("%s", address);
......

Я не знаком с gdbus, и если вы хотите копать глубже, я предлагаю вам проверить официальный сайт: http://developer.gnome.org/gio/stable/gdbus-convenience.html

============================

лол

Тогда вам просто нужно проверить каталог 'test' исходного кода bluez.

Есть примеры как на Python, так и на C.

Кроме того, интерфейс bluez dbus сильно изменился с 3.XX на 4.XX, так что проверьте правильную версию.

...