The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Введение в D-BUS (dbus hardware linux ipc kde)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: dbus, hardware, linux, ipc, kde,  (найти похожие документы)
From: Роман Химов Date: Mon, 26 Jan 2008 18:21:07 +0000 (UTC) Subject: Введение в D-BUS Оригинал: Chip Special Linux, http://citkit.ru/articles/243/ Посредник D-BUS Понятие настольной среды подразумевает нечто цельное и тесно переплетенное между собой, однако среда формируется приложениями, а они как-то должны друг с другом общаться, интегрируясь в нее. В мире KDE для этого давно и небезуспешно используется DCOP, но вот в других настольных средах (например, GNOME) дела все время обстояли не так хорошо. Конечно, существовала возможность коммуникации посредством CORBA, SOAP или XML-RPC, но первый очень уж тяжеловат и неудобен (причем, надо заметить, что и KDE, и GNOME прошли этап его использования за время своего существования), а оставшиеся не так быстры, как хотелось бы, да и предназначены они для совсем других целей. До недавнего времени GNOME использовал Bonobo, который, в свою очередь, был основан на CORBA, но в связи с зависимостью от GObject более Bonobo нигде не использовался, да и тяжесть CORBA по-прежнему давила на всю среду. А ведь хотелось бы, чтобы свободно общаться между собой могли не только приложения одной среды, но и разных. На это и направлен новый стандарт D-BUS, разрабатываемый обществом freedesktop.org. Продукт легковесен и очень быстр в работе, он не зависит от конкретной среды, но при этом прекрасно интегрируется в каждую из них. D-BUS также легко доступен из разных программных сред (Glib, Java (GCJ), Mono, Qt, Python) и прозрачен для сети. Что такое D-BUS? D-BUS -- это механизм IPC (InterProcess Communication), который предоставляет шину для передачи сообщений, ну а если быть точнее, то сразу несколько шин. Первая и самая главная -- системная шина, она создается уже при старте демона D-BUS, и с ее помощью происходит общение различных демонов. Она хорошо защищена от посторонних, и пользовательские приложения, хоть и могут подключаться к ней, все же будут значительно ограничены в том, какие сообщения они смогут туда посылать (в то же время они могут многое <<услышать>>). Реальная же рабочая лошадка D-BUS -- сессионная шина, создаваемая для любого пользователя, авторизующегося в системе. Для каждой такой шины запускается отдельная копия демона, и именно посредством нее будут общаться приложения, с которыми работает этот пользователь. Каждое сообщение D-BUS, передаваемое по шине, имеет своего отправителя и своего получателя, их адреса называются путями объектов, поскольку D-BUS предполагает, что каждое приложение состоит из набора объектов, а сообщения пересылаются не между приложениями, а между объектами этих самых приложений. Для идентификации объектов используются пути, именуемые в стиле Unix. Так, например, сам D-BUS доступен по адресу /org/freedesktop/DBus. Каждый объект может поддерживать один или более интерфейсов, которые представлены здесь в виде именованных групп методов и сигналов -- аналогично интерфейсам Glib, Qt или Java. Именуются они привычным для ОО-программистов образом, например рассматриваемый D-BUS экспортирует интерфейс org.freedesktop.DBus. Однако объектов и интерфейсов маловато для реализации некоторых интересных возможностей, и D-BUS также предусматривает концепцию сервисов. Сервис -- уникальное местоположение приложения на шине. При запуске приложение регистрирует один или несколько сервисов, которыми оно будет владеть до тех пор, пока самостоятельно не освободит, до этого момента никакое другое приложение, претендующее на тот же сервис, занять его не сможет. Именуются сервисы аналогично интерфейсам, а сам D-BUS экспортирует, соответственно, сервис org.freedesktop.DBus. Принципы работы Сервисы делают доступной еще одну функцию -- запуск необходимых приложений в случае поступления сообщений для них. Для этого должна быть включена автоактивация, и в конфигурации D-BUS за этим сервисом должно быть закреплено одно приложение. Тогда D-BUS сможет его запустить при появлении сообщения. После закрытия приложения ассоциированные сервисы также разрегистрируются, а D-BUS посылает сигнал о том, что сервис закрыт. Другие приложения могут получать такие сигналы и соответствующим образом реагировать. После подключения к шине приложение должно указать, какие сообщения оно желает получать, путем добавления масок совпадений (matchers). Маски представляют собой наборы правил для сообщений, которые будут доставляться приложению, фильтрация может основываться на интерфейсах, путях объектов и методах. Таким образом, приложения будут получать только то, что им необходимо, проблемы доставки в этом случае берет на себя D-BUS. Сообщения в D-BUS бывают четырех видов: вызовы методов, результаты вызовов методов, сигналы и ошибки. Первые предназначены для выполнения методов над объектами, подключенными к D-BUS; посылая такое сообщение, вы выдаете задание объекту, а он после обработки обязан возвратить вам либо результат вызова, либо ошибку через сообщения соответствующих типов. Сигнальные же сообщения, как им и полагается, ничуть не заботятся о том, что и как делается объектами, они вольны воспринимать их как угодно (равно как и не получать их вовсе). Естественно, для нормальной работы вызовов методов между различными средами/языками D-BUS стандартизирует типы передаваемых данных (параметров). Мы не будем их перечислять, поскольку это не имеет смысла, однако отметим, что интерфейсы D-BUS строго типизированы, и D-BUS всегда выполняет проверку корректности передаваемых по интерфейсу данных, не доверяя никому. Системная шина D-BUS защищена от вредных приложений. Каким же образом это реализовано? Ответ располагается по адресу /etc/dbus-1/system.d/ -- там можно обнаружить различные конфигурационные файлы, с помощью которых осуществляется очень гибкая настройка доступа к тем или иным сервисам и интерфейсам. Впрочем, если этой гибкости мало, можно сделать еще больше, подключив возможность использования контекстов безопасности SELinux. В базовый протокол D-BUS также встроены методы аутентификации клиентов, обращающихся с вызовами, однако они практически не используются. Пример работы Посмотрите на следующий пример использования механизма D-BUS из Python: код взят из документации к другому любимому нами компоненту -- HAL: # !/usr/bin/python import gtk import dbus def device_added(interface, signal_name, service, path, message): [udi] = message.get_args_list () print 'Device %s was added'%udi def device_removed(interface, signal_name, service, path, message): [udi] = message.get_args_list () print 'Device %s was removed'%udi bus = dbus.Bus (dbus.Bus.TYPE_SYSTEM) hal_service = bus.get_service ('org.freedesktop.Hal') hal_manager = hal_service.get_object ('/org/freedesktop/Hal/Manager', 'org.freedesktop.Hal.Manager') bus.add_signal_receiver (device_added, 'DeviceAdded', 'org.freedesktop.Hal.Manager', 'org.freedesktop.Hal', '/org/freedesktop/Hal/Manager') bus.add_signal_receiver (device_removed, 'DeviceRemoved', 'org.freedesktop.Hal.Manager', 'org.freedesktop.Hal', '/org/freedesktop/Hal/Manager') gtk.main() Запустите такой скрипт и поиграйте с устройствами -- подключите/отключите мышку, принтер, сканер, еще что-нибудь. Все эти действия будут сопровождаться сообщениями от скрипта, поскольку он ловит сигналы device_added и device_removed от HAL через D-BUS (на системной шине). Согласитесь, отловить эти сообщения совсем несложно, зато представьте, сколько всего полезного можно сделать (если чуть-чуть расширить скрипт на предмет более подробных расспросов HAL об устройстве)! Применения Разработчики KDE пока еще только начали осваивать D-BUS, что, в общем-то, и понятно: DCOP не намного хуже D-BUS (надо отметить, что последний учел опыт первого в разработке), но с ним KDE работает уже давно. Однако есть проект перевода DCOP на использование D-BUS в качестве транспорта, да и, как уже было сказано, освоение уже пошло (все, что относится к взаимодействию с HAL в KDE, также протекает посредством D-BUS). А вот GNOME уже активно использует D-BUS в своих приложениях, одни примеры его применения вместе с HAL многого стоят (что интересно, HAL без D-BUS был бы довольно скучен, но и D-BUS смог по-настоящему показать свои прелести только на HAL). Однако этим его использование отнюдь не ограничивается -- во-первых, GNOME сейчас активно избавляется от Bonobo, и здесь D-BUS начинает тихо и без лишнего шума выполнять свою основную работу, пусть и не с первого взгляда заметную пользователю. Во-вторых, наличие удобного транспорта уже навело некоторых разработчиков на мысли о том, что с его помощью можно легко обобщать многие части общего кода приложений, создавая сервисы D-BUS, которые фактически становятся очень интересной альтернативой обычным разделяемым библиотекам, которые, в свою очередь, будут доступны из любых языков и сред. Поэтому, как и в случае с HAL, все самое интересное еще впереди.

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ RSS ]
 
  • 1, очень жаль, 04:04, 27/03/2008 [ответить] [смотреть все]
  • +/
    Статья вроде новая 2008 года.
    Но написана для старого API, 3 летней давности.
    В любом современном дистрибутиве данный пример выдаст типа:

    Traceback (most recent call last):
      File "./test.py", line 15, in ?
        hal_service = bus.get_service ('org.freedesktop.Hal')
    AttributeError: 'SystemBus' object has no attribute 'get_service'

     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor TopList