WikiDer > D-автобус

D-Bus
"DBus" перенаправляется сюда. Для тибетской провинции см. Dbus.
D-автобус
Разработчики)Красная шляпа
изначальный выпускНоябрь 2006 г.; 14 лет назад (2006-11)
Стабильный выпуск
1.12.20 / 2 июля 2020 г.; 5 месяцев назад (2020-07-02)[1]
Предварительный выпуск
1.13.18 / 2 июля 2020 г.; 5 месяцев назад (2020-07-02)[2]
Репозиторий
Отредактируйте это в Викиданных
Написано вC
Операционная системаКроссплатформенность
Тип
ЛицензияGPLv2 + или же AFL 2.1[3]
Интернет сайтwww.freedesktop.org/ wiki/Программного обеспечения/ dbus

В вычисление, D-автобус (Короче для "Настольный автобус"[4])это программная шина, межпроцессного взаимодействия (IPC) и удаленный вызов процедур (RPC) механизм, обеспечивающий связь между несколькими процессы работают одновременно на одном компьютере.[5][6] D-Bus был разработан как часть freedesktop.org проект, инициированный Havoc Pennington из Красная шляпа стандартизировать услуги, предоставляемые Linux окружения рабочего стола Такие как ГНОМ и KDE.[7][8][мертвая ссылка]

Проект freedesktop.org также разработал бесплатно и с открытым исходным кодом программная библиотека под названием libdbus, как эталонная реализация спецификации. Эту библиотеку не следует путать с самим D-Bus, поскольку существуют и другие реализации спецификации D-Bus, такие как GDBus (GNOME),[9] QtDBus (Qt/ KDE),[10] dbus-java[11] и sd-bus (часть systemd).[12]

Обзор

D-Bus - это механизм IPC, изначально разработанный для замены программный компонент системы связи, используемые ГНОМ и KDE Linux окружения рабочего стола (CORBA и DCOP соответственно).[13][14] Компоненты этих сред рабочего стола обычно распределяются по множеству процессов, каждый из которых обеспечивает лишь несколько - обычно один - Сервисы. Данными услугами может пользоваться постоянный клиент. Приложения или другими компонентами среды рабочего стола для выполнения своих задач.

Процессы без D-Bus
Процессы без D-Bus
Процессы с D-Bus
Те же процессы с D-Bus
Большие группы взаимодействующих процессов требуют плотной сети отдельных каналов связи (с использованием методов IPC «один-к-одному») между ними. D-Bus упрощает требования IPC с помощью одного общего канала.

Из-за большого количества задействованных процессов - добавления процессов, предоставляющих услуги, и клиентов, получающих к ним доступ - установление IPC-коммуникаций «один-к-одному» между всеми ними становится неэффективным и весьма ненадежным.[нужна цитата] подход. Вместо этого D-Bus предоставляет программная шина абстракция который собирает все сообщения между группой процессов по одному общему виртуальному каналу.[6] Процессы, подключенные к шине, не знают, как это реализовано внутри, но спецификация D-Bus гарантирует, что все процессы, подключенные к шине, могут общаться друг с другом через нее.

Среды рабочего стола GNU + Linux используют возможности D-Bus, создавая экземпляры не одной шины, а множества:[15][6][16]

  • один системная шина, доступный для всех пользователей и процессов системы, который обеспечивает доступ к системным сервисам (т. е. сервисам, предоставляемым Операционная система а также любой системой демоны)
  • а сессионный автобус для каждого сеанса входа пользователя, который предоставляет сервисы рабочего стола для пользовательских приложений в одном сеансе рабочего стола и позволяет интегрировать сеанс рабочего стола в целом

Процесс может подключаться к любому количеству шин при условии, что ему предоставлен доступ к ним. На практике это означает, что любой пользовательский процесс может подключаться к системной шине и к своей текущей сеансовой шине, но не к сеансовым шинам другого пользователя или даже к другой сеансовой шине, принадлежащей тому же пользователю. Последнее ограничение может измениться в будущем, если все пользовательские сеансы объединены в единую пользовательскую шину.[17]

D-Bus обеспечивает дополнительные или упрощает существующие функции приложений, включая обмен информацией, модульность и разделение привилегий. Например, информация о входящем голосовом вызове, полученном через Bluetooth или же Skype может передаваться и интерпретироваться любым работающим в данный момент музыкальным проигрывателем, который может отреагировать отключением громкости или приостановкой воспроизведения до завершения вызова.[18]

D-Bus также можно использовать как рамки для интеграции различных компонентов пользовательского приложения. Например, офисная одежда может общаться через шину сеанса для обмена данными между текстовый редактор и электронная таблица.

Спецификация D-Bus

Модель автобуса

Каждое подключение к шине идентифицируется в контексте D-Bus тем, что называется название автобуса.[5] Имя шины состоит из двух или более разделенных точками строк букв, цифр, тире и подчеркиваний. Пример действительного названия автобуса: org.freedesktop.NetworkManager.[6]

Когда процесс устанавливает соединение с шиной, шина назначает соединению специальное имя шины, называемое уникальное имя соединения.[16][6] Имена шин этого типа неизменяемы - гарантируется, что они не изменятся, пока существует соединение, и, что более важно, они не могут быть повторно использованы в течение срока службы шины.[5][16][6] Это означает, что никакому другому соединению с этой шиной никогда не будет присвоено такое уникальное имя соединения, даже если тот же процесс закрывает соединение с шиной и создает новое. Уникальные имена соединений легко распознать, поскольку они начинаются с символа двоеточия - в противном случае это запрещено.[16][6] Пример уникального имени подключения: :1.1553 (символы после двоеточия не имеют особого значения[16]).

Процесс может запрашивать дополнительные имена шины для своего подключения,[16] при условии, что любое запрошенное имя еще не используется другим подключением к шине. На языке D-Bus, когда соединению присваивается имя шины, говорят, что соединение владеет название автобуса.[5][16] В этом смысле имя шины не может принадлежать двум соединениям одновременно, но, в отличие от уникальных имен соединений, эти имена можно использовать повторно, если они доступны: процесс может вернуть выпущенное имя шины - намеренно или нет - другим процессом.[5][6]

Идея этих дополнительных имен автобусов, обычно называемых известные имена, заключается в том, чтобы обеспечить способ обращения к службе с использованием заранее заданного имени шины.[16][6] Например, служба, которая сообщает текущее время и дату на системной шине, находится в процессе, соединение которого владеет org.freedesktop.timedate1 имя шины, независимо от того, какой это процесс.

Имена шин можно использовать как простой способ реализации приложений с одним экземпляром (вторые экземпляры обнаруживают, что имя шины уже занято).[16] Его также можно использовать для отслеживания жизненного цикла процесса обслуживания, поскольку шина отправляет уведомление, когда имя шины освобождается из-за завершения процесса.[16]

Объектная модель

Из-за своей первоначальной концепции как замены нескольких компонентно-ориентированных систем связи, D-Bus разделяет со своими предшественниками объектную модель, в которой выражается семантика связи между клиентами и сервисами. Термины, используемые в объектной модели D-Bus, имитируют термины, используемые некоторыми объектно-ориентированный языки программирования. Это не означает, что D-Bus каким-то образом ограничен языками ООП - на самом деле, это наиболее часто используемая реализация (libdbus) написано в C, а процедурное программирование язык.

Просмотр существующих имен шин, объектов, интерфейсов, методов и сигналов в шине D-Bus с помощью D-Feet

В D-Bus процесс предлагает свои услуги, открывая объекты. Эти объекты имеют методы который может быть вызван, и сигналы что объект может излучать.[16] Методы и сигналы вместе именуются члены объекта.[5] Любой клиент, подключенный к шине, может взаимодействовать с объектом, используя его методы, делая запросы или отдавая команду объекту на выполнение действий.[16] Например, объект, представляющий службу времени, может быть запрошен клиентом с помощью метода, который возвращает текущую дату и время. Клиент также может прослушивать сигналы, которые излучает объект, когда его состояние изменяется из-за определенных событий, обычно связанных с базовой службой. Примером может служить служба, которая управляет аппаратными устройствами, такими как USB или сетевые драйверы, сигнализирует о событии «добавлено новое аппаратное устройство». Клиенты должны проинструктировать шину о том, что они заинтересованы в получении определенных сигналов от конкретного объекта, поскольку шина D-Bus передает сигналы только тем процессам, у которых зарегистрирован интерес к ним.[6]

Процесс, подключенный к шине D-Bus, может запросить его экспорт столько объектов D-Bus, сколько он хочет. Каждый объект идентифицируется путь к объекту, строка цифр, букв и знаков подчеркивания, разделенных и предваренных символом косой черты, названная так из-за их сходства с Пути файловой системы Unix.[5][16] Путь к объекту выбирается запрашивающим процессом и должен быть уникальным в контексте данного шинного соединения. Пример действительного пути к объекту: / org / kde / kspread / sheet / 3 / cells / 4/5.[16] Однако не принуждают - но и не препятствуют - формировать иерархии внутри путей к объектам.[6] Конкретное соглашение об именах для объектов службы полностью зависит от разработчиков такой службы, но многие разработчики предпочитают пространство имен они используют зарезервированные доменное имя проекта в качестве префикса (например, / org / kde).[16]

Каждый объект неразрывно связан с конкретным шинным соединением, на которое он был экспортирован, и, с точки зрения D-Bus, живет только в контексте такого соединения. Следовательно, чтобы иметь возможность использовать определенную службу, клиент должен указать не только путь к объекту, предоставляющий желаемую службу, но также имя шины, под которой процесс службы подключен к шине.[5] Это, в свою очередь, позволяет нескольким процессам, подключенным к шине, однозначно экспортировать разные объекты с идентичными путями к объектам.

Члены - методы и сигналы - которые могут использоваться с объектом, указываются интерфейс.[16] An интерфейс представляет собой набор объявлений методов (включая параметры передачи и возврата) и сигналов (включая параметры), идентифицируемых разделенным точками именем, напоминающим Язык Java обозначение интерфейсов.[16][6] Пример действительного имени интерфейса: org.freedesktop.Introspectable.[6] Несмотря на их схожесть, имена интерфейсов и имена шин не должны ошибаться. Объект D-Bus может воплощать в жизнь несколько интерфейсов, но по крайней мере должен реализовывать один, обеспечивая поддержку каждого метода и сигнала, определенных им. Комбинация всех интерфейсов, реализованных объектом, называется объектом. тип.[5][16]

При использовании объекта хорошей практикой для клиентского процесса является предоставление имени интерфейса члена помимо имени члена, но это обязательно только в том случае, если существует неоднозначность, вызванная дублированием имен членов, доступных из разных интерфейсов, реализованных объектом.[5][16] - в противном случае выбранный элемент не определен или ошибочен. С другой стороны, излучаемый сигнал всегда должен указывать, какому интерфейсу он принадлежит.

Спецификация D-Bus также определяет несколько стандартных интерфейсов, которые объекты могут захотеть реализовать в дополнение к своим собственным интерфейсам.[15] Хотя это технически необязательно, большинство разработчиков сервисов D-Bus предпочитают поддерживать их в своих экспортированных объектах, поскольку они предлагают важные дополнительные функции для клиентов D-Bus, такие как самоанализ.[6] Эти стандартные интерфейсы:[15][6]

  • org.freedesktop.DBus.Peer: предоставляет способ проверить, живо ли соединение D-Bus.[6]
  • org.freedesktop.DBus.Introspectable: предоставляет механизм самоанализа, с помощью которого клиентский процесс может во время выполнения получить описание (в XML формат) интерфейсов, методов и сигналов, которые реализует объект.[16][15]
  • org.freedesktop.DBus.Properties: позволяет объекту D-Bus раскрывать базовый собственный объект характеристики или атрибуты, или смоделировать их, если они не существуют.[15]
  • org.freedesktop.DBus.ObjectManager: когда служба D-Bus упорядочивает свои объекты иерархически, этот интерфейс предоставляет способ запросить объект обо всех подобъектах на его пути, а также об их интерфейсах и свойствах, используя один вызов метода.[15]

Спецификация D-Bus определяет ряд операций административной шины (называемых «автобусными службами»), которые должны выполняться с использованием / org / freedesktop / DBus объект, который находится в org.freedesktop.DBus название автобуса.[15] Каждая шина резервирует это специальное имя шины для себя и управляет любыми запросами, сделанными специально для этой комбинации имени шины и пути объекта. Административные операции, обеспечиваемые шиной, определяются интерфейсом объекта. org.freedesktop.DBus. Эти операции используются, например, для предоставления информации о состоянии автобуса,[5] или для управления запросом и выпуском дополнительных хорошо известный названия автобусов.[15][6]

Модель коммуникации

D-Bus был задуман как универсальная система межпроцессного взаимодействия высокого уровня. Для достижения этих целей связь D-Bus основана на обмене Сообщения между процессами вместо "сырых байтов".[5][16] Сообщения D-Bus - это дискретные элементы высокого уровня, которые процесс может отправить через шину другому подключенному процессу. Сообщения имеют четко определенную структуру (определены даже типы данных, переносимых в их полезной нагрузке), что позволяет шине проверять их и отклонять любое некорректно сформированное сообщение. В этом отношении D-Bus ближе к RPC механизм, чем классический механизм IPC, с его собственной системой определения типов и собственной маршалинг.[5]

Пример обмена сообщениями типа "запрос-ответ" один-к-одному для вызова метода через D-Bus. Здесь клиентский процесс вызывает SetFoo () метод / org / example / object1 объект из сервисного процесса с именем org.example.foo (или же :1.14) в автобусе.

Шина поддерживает два режима обмена сообщениями между клиентом и сервисным процессом.[5]:

  • Один к одному ответ на запрос: Это способ, которым клиент может вызвать метод объекта. Клиент отправляет сообщение процессу службы, экспортирующему объект, а служба, в свою очередь, отвечает сообщением обратно клиентскому процессу.[16] Сообщение, отправленное клиентом, должно содержать путь к объекту, имя вызванного метода (и, возможно, имя его интерфейса) и значения входных параметров (если есть), как определено выбранным интерфейсом объекта. В ответном сообщении содержится результат запроса, включая значения выходных параметров, возвращаемых вызовом метода объекта, или исключение информация, если произошла ошибка.[5][16]
  • Опубликовать / подписаться: Это способ, которым объект сообщает заинтересованным сторонам о возникновении сигнала. Процесс обслуживания объекта передает сообщение, которое шина передает только подключенным клиентам, подписавшимся на сигнал объекта.[16] Сообщение содержит путь к объекту, имя сигнала, интерфейс, которому принадлежит сигнал, а также значения параметров сигнала (если есть). Связь является односторонней: нет ответных сообщений на исходное сообщение от какого-либо клиентского процесса, поскольку отправитель не знает ни идентификаторов, ни количества получателей.[5][16]

Каждое сообщение D-Bus состоит из заголовка и тела.[16] Заголовок состоит из нескольких полей, которые определяют тип сообщения, отправителя, а также информацию, необходимую для доставки сообщения его получателю (имя шины назначения, путь к объекту, имя метода или сигнала, имя интерфейса и т. Д.).[16][15] Тело содержит полезные данные, которые интерпретирует процесс-получатель, например, входные или выходные аргументы. Все данные закодированы в хорошо известном двоичном формате, называемом формат провода который поддерживает сериализация различных типов, таких как целые числа и числа с плавающей запятой, строки, составные типы и т. д.,[15] также упоминается как маршалинг.

Спецификация D-Bus определяет проводной протокол: как создать сообщения D-Bus для обмена между процессами в рамках соединения D-Bus. Однако он не определяет базовый транспортный метод для доставки этих сообщений.

Внутренности

Большинство существующих реализаций D-Bus следуют архитектуре эталонной реализации. Эта архитектура состоит из двух основных компонентов:[5]

  • связь точка-точка библиотека который реализует D-Bus проводной протокол для обмена сообщениями между двумя процессами. В эталонной реализации эта библиотека libdbus. В других реализациях libdbus может быть обернут другой библиотекой более высокого уровня, языковой привязкой или полностью заменен другой автономной реализацией, служащей той же цели.[19] Эта библиотека поддерживает только однозначное взаимодействие между двумя процессами.[16]
  • А dbus-демон процесс, действующий как демон шины сообщений D-Bus. Каждый процесс, подключенный к шине, поддерживает с ней одно соединение D-Bus.
    специальный демон процесс которая играет роль шины и к которой подключаются остальные процессы, используя любую библиотеку связи точка-точка D-Bus. Этот процесс также известен как демон шины сообщений,[18] поскольку он отвечает за маршрутизацию сообщений от любого процесса, подключенного к шине, к другому. В эталонной реализации эту роль выполняет dbus-демон, который сам построен поверх libdbus. Другая реализация демона шины сообщений: dbus-брокер, который построен поверх SD-автобус.
Процессы A и B имеют прямое соединение D-Bus между ними через сокет домена Unix.
Процессы A и B имеют однозначное соединение D-Bus с использованием libdbus через сокет домена Unix. Они могут использовать его для прямого обмена сообщениями.[20] В этом сценарии имена шины не требуются.[16]
Процесс A и B имеют однозначное соединение D-Bus с процессом dbus-daemon через сокет домена Unix.
Оба процесса A и B подключены к dbus-демон с помощью libdbus через сокет домена Unix. Они могут обмениваться сообщениями, отправляя их процессу шины сообщений, который, в свою очередь, доставляет сообщения соответствующему процессу. В этом сценарии имена шины являются обязательными для идентификации процесса назначения.

В libdbus библиотека (или ее эквивалент) внутренне использует собственный механизм IPC нижнего уровня для передачи требуемых сообщений D-Bus между двумя процессами на обоих концах соединения D-Bus. Спецификация D-Bus не указывает, какие конкретные транспортные механизмы IPC должны быть доступны для использования, поскольку именно коммуникационная библиотека решает, какие транспортные методы она поддерживает. Например, в Linux и Unix-подобных операционных системах libdbus обычно использует Доменные сокеты Unix в качестве основного транспортного метода, но он также поддерживает Сокеты TCP.[5][16]

Коммуникационные библиотеки обоих процессов должны согласовать выбранный метод передачи, а также конкретный канал, используемый для их связи. Эта информация определяется тем, что D-Bus называет адрес.[6][16] Доменный сокет Unix файловая система объекты, и поэтому они могут быть идентифицированы по имени файла, поэтому действительный адрес будет unix: путь = / tmp / .hiddensocket.[5][15] Оба процесса должны передать один и тот же адрес своим соответствующим коммуникационным библиотекам для установления соединения D-Bus между ними. Адрес также может предоставлять дополнительные данные в коммуникационную библиотеку в виде разделенных запятыми ключ = значение пары.[6][15] Таким образом, например, он может предоставить информацию аутентификации для определенного типа соединения, которое его поддерживает.

Когда демон шины сообщений, например dbus-демон используется для реализации шины D-Bus, все процессы, которые хотят подключиться к шине, должны знать адрес автобуса, адрес, по которому процесс может установить соединение D-Bus с процессом центральной шины сообщений.[5][16] В этом сценарии демон шины сообщений выбирает адрес шины, а остальные процессы должны передать это значение в соответствующие libdbus или эквивалентные библиотеки. dbus-демон определяет другой адрес шины для каждого экземпляра шины, который он предоставляет. Эти адреса определены в файлах конфигурации демона.

Два процесса могут использовать соединение D-Bus для обмена сообщениями напрямую между собой.[20], но D-Bus обычно не предназначен для использования таким образом. Обычный способ - всегда использовать демон шины сообщений (т.е. dbus-демон) как центральную точку связи, с которой каждый процесс должен установить свое двухточечное соединение D-Bus. Когда процесс - клиент или служба - отправляет сообщение D-Bus, процесс шины сообщений получает его в первую очередь и доставляет соответствующему получателю. Демон шины сообщений может рассматриваться как концентратор или маршрутизатор, отвечающий за доставку каждого сообщения к месту назначения, повторяя его через соединение D-Bus с процессом получателя.[16] Процесс-получатель определяется именем целевой шины в поле заголовка сообщения,[15] или посредством информации подписки на сигналы, поддерживаемые демоном шины сообщений в случае сообщений распространения сигналов.[6] Демон шины сообщений также может создавать свои собственные сообщения в ответ на определенные условия, например, сообщение об ошибке для процесса, который отправил сообщение на несуществующее имя шины.[16]

dbus-демон улучшает набор функций, уже предоставленный самим D-Bus, с дополнительными функциями. Например, активация услуги позволяет автоматически запускать службы при необходимости - когда первый запрос к любому имени шины такой службы поступает на демон шины сообщений.[5] Таким образом, служебные процессы не нужно запускать во время инициализация системы или этап инициализации пользователя, и они не должны потреблять память или другие ресурсы, когда они не используются. Эта функция изначально была реализована с использованием Setuid помощники,[21] но в настоящее время это также может быть предоставлено systemdрамки активации услуг.[нужна цитата] Активация службы - это важная функция, которая облегчает управление жизненным циклом служб (например, когда компонент рабочего стола должен запускаться или останавливаться).[16]

История и усыновление

D-Bus был запущен в 2002 году Хавоком Пеннингтоном, Алексом Ларссоном (Красная шляпа) и Андерс Карлссон.[8] Версия 1.0 - считается API стабильный - выпущен в ноябре 2006 года.[22][23]

В dbus-демон играет значительную роль в современном Linux графические среды рабочего стола.

Находился под сильным влиянием DCOP система, используемая версиями 2 и 3 KDE, D-Bus заменил DCOP в KDE 4 релиз.[23][24] Реализация D-Bus поддерживает большинство POSIX операционные системы и порт для Windows существуют. Он используется Qt 4 и ГНОМ. В GNOME он постепенно заменил большую часть более ранних Бонобо механизм. Он также используется Xfce.

Одним из первых последователей был (в настоящее время не рекомендуется) Уровень аппаратной абстракции. HAL использовал D-Bus для экспорта информации об оборудовании, которое было добавлено или удалено с компьютера.[8]

Использование D-Bus неуклонно расширяется за пределы первоначальной области настольных сред, чтобы охватить все большее количество системных служб. Например, Сетевой менеджер сетевой демон, BlueZ стек bluetooth и PulseAudio звуковой сервер использует D-Bus для предоставления части или всех своих услуг. systemd использует проводной протокол D-Bus для связи между systemctl и systemd, а также продвигает традиционные системные демоны в сервисы D-Bus, такие как logind.[25] Еще один активный пользователь D-Bus - Polkit, демон полномочий политик которого реализован как служба, подключенная к системной шине.[26]

Он также используется как Проводной протокол для AllJoyn протокол для Домашняя автоматизация, с этой целью AllJoyn добавляет обнаружение, управление сеансами, безопасность, сжатие заголовков, поддержку встроенных устройств и делает его независимым от транспорта.[27]

Реализации

libdbus

Хотя существует несколько реализаций D-Bus, наиболее широко используется эталонная реализация. libdbus, разработанный тем же проектом freedesktop.org, который разработал спецификацию. Однако libdbus - это реализация низкого уровня, которая никогда не предназначалась для непосредственного использования разработчиками приложений, а использовалась в качестве справочного руководства для других повторных реализаций D-Bus (например, тех, которые включены в стандартные библиотеки окружений рабочего стола или в язык программирования привязки). Сам проект freedesktop.org рекомендует авторам приложений вместо этого «использовать одну из привязок или реализаций более высокого уровня».[28] Преобладание libdbus как наиболее используемой реализации D-Bus привело к тому, что термины «D-Bus» и «libdbus» часто использовались взаимозаменяемо, что приводило к путанице.

GDBus

GDBus[9] это реализация D-Bus на основе GIO потоки включен в GLib, с целью использования GTK + и ГНОМ. GDBus - это не оболочка libdbus, а полная и независимая реализация спецификации и протокола D-Bus.[29] Рабочий стол MATE[30] и Xfce (версия 4.14), которые также основаны на GTK + 3, также используют GDBus.

QtDBus

QtDBus[10] это реализация D-Bus, включенная в Библиотека Qt начиная с его версии 4.2. Этот компонент используется KDE приложения, библиотеки и компоненты для доступа к службам D-Bus, доступным в системе.

SD-автобус

В 2013 г. systemd проект переписал libdbus, чтобы упростить код,[31] но это также привело к значительному увеличению общей производительности D-Bus. В предварительных тестах BMW обнаружил, что библиотека D-Bus systemd повысила производительность на 360%.[32] По версии 221 из systemd, sd-автобус API был объявлен стабильным.[33]

libnih-dbus

Проект libnih предоставляет облегченную «стандартную библиотеку» поддержки C для D-Bus. Кроме того, он имеет хорошую поддержку кросс-компиляции.

kdbus

kdbus реализован как драйвер символьного устройства.[34][35] Все коммуникации между процессами происходят через узлы специальных символьных устройств в / dev / kdbus (ср. devfs).

kdbus был проектом, целью которого было переопределить D-Bus как одноранговую сеть, опосредованную ядром. межпроцессного взаимодействия механизм. Помимо повышения производительности, kdbus будет иметь преимущества, вытекающие из других Ядро Linux такие функции, как пространства имен и аудит,[32][36] безопасность от посредника ядра, закрытие условий гонки и разрешение использования D-Bus во время загрузки и завершения работы (по необходимости systemd).[37] Включение kdbus в ядро ​​Linux оказалось спорным,[38] и был отклонен в пользу BUS1, как более общий межпроцессного взаимодействия.[39]

Языковые привязки

Несколько языков программирования привязки для D-Bus были разработаны,[40] такие как для Ява, C # и Рубин.

Смотрите также

Рекомендации

  1. ^ "Журнал изменений D-Bus 1.12.x". Получено 5 августа 2018.
  2. ^ "Файл НОВОСТЕЙ для текущей ветки". Получено 14 ноября 2018.
  3. ^ Блог Havoc июль 2007 г.
  4. ^ Уорд, Брайан (2004). «14: Краткий обзор рабочего стола Linux». Как работает Linux: что должен знать каждый суперпользователь (2-е изд.). Сан-Франциско: No Starch Press (опубликовано в 2014 г.). п. 305. ISBN 9781593275679. Получено 2016-11-07. Одним из наиболее важных достижений, появившихся в настольных системах Linux, является шина рабочего стола (D-Bus), система передачи сообщений. D-Bus важен, потому что он служит механизмом межпроцессного взаимодействия, который позволяет настольным приложениям общаться друг с другом [...].
  5. ^ а б c d е ж грамм час я j k л м п о п q р s т ты Вермёлен, Йерун (14 июля 2013 г.). «Введение в D-Bus». FreeDesktop.org. Получено 22 октября 2015.
  6. ^ а б c d е ж грамм час я j k л м п о п q р s т Кокань, Том (август 2012). "Обзор DBus". pythonhosted.org. Получено 22 октября 2015.
  7. ^ Вермёлен, Йерун (14 июля 2013 г.). «Введение в D-Bus». FreeDesktop.org. Получено 3 октября 2015. D-Bus [...] разработан для использования в качестве единого промежуточного уровня под основными средами бесплатного рабочего стола.
  8. ^ а б c Пальмиери, Джон (январь 2005 г.). "Садись на D-BUS". Журнал Red Hat. Архивировано из оригинал 23 октября 2015 г.. Получено 3 ноября 2015.
  9. ^ а б "gdbus". Разработчик GNOME. Получено 4 января 2015.
  10. ^ а б "Модуль QtDBus". Qt Project. Получено 1 июня 2015.
  11. ^ «Документация DBus-Java». FreeDesktop.org. Получено 4 января 2015.
  12. ^ Поэтинг, Леннарт (19 июня 2015). "Новый sd-bus API systemd". Получено 21 октября 2015.
  13. ^ Пеннингтон, Хаос; Уиллер, Дэвид; Уолтерс, Колин. "Учебное пособие по D-Bus". Получено 21 октября 2015. Для случая использования в рамках сеанса рабочего стола рабочие столы GNOME и KDE имеют значительный предыдущий опыт работы с различными решениями IPC, такими как CORBA и DCOP.D-Bus основан на этом опыте и тщательно адаптирован для удовлетворения потребностей, в частности, этих настольных проектов.
  14. ^ Вермёлен, Йерун (14 июля 2013 г.). «Введение в D-Bus». FreeDesktop.org. Получено 3 октября 2015. D-Bus был впервые создан для замены CORBA-подобной компонентной модели, лежащей в основе среды рабочего стола GNOME. Подобно DCOP (который используется KDE), D-Bus станет стандартным компонентом основных бесплатных сред рабочего стола для GNU / Linux и других платформ.
  15. ^ а б c d е ж грамм час я j k л м Пеннингтон, Хаос; Карлссон, Андерс; Ларссон, Александр; Герцберг, Свен; МакВитти, Саймон; Цойтен, Давид. «Спецификация D-Bus». Freedesktop.org. Получено 22 октября 2015.
  16. ^ а б c d е ж грамм час я j k л м п о п q р s т ты v ш Икс у z аа ab ac объявление ае аф аг ах ай Пеннингтон, Хаос; Уиллер, Дэвид; Уолтерс, Колин. "Учебное пособие по D-Bus". Получено 21 октября 2015.
  17. ^ Поэтинг, Леннарт (19 июня 2015). "Новый sd-bus API systemd". Получено 21 октября 2015. мы работаем над перемещением вещей на настоящую пользовательскую шину, из которой на каждого пользователя в системе приходится только одна, независимо от того, сколько раз этот пользователь входит в систему
  18. ^ а б С любовью, Роберт (5 января 2005 г.). "Садись на D-BUS". Linux журнал. Получено 14 октября 2014.
  19. ^ "Что такое D-Bus?". FreeDesktop.org. Получено 29 октября 2015. Существуют также некоторые переопределения протокола D-Bus для таких языков, как C #, Java и Ruby. Они не используют эталонную реализацию libdbus
  20. ^ а б "Что такое D-Bus?". FreeDesktop.org. Получено 29 октября 2015. построен на основе общей структуры передачи сообщений один-к-одному, которая может использоваться любыми двумя приложениями для прямой связи (без прохождения через демон шины сообщений)
  21. ^ «Активация системы D-BUS». FreeDesktop.org. Получено 18 февраля 2016.
  22. ^ Пальмиери, Джон (9 ноября 2006 г.). "[объявить] Выпущен D-Bus 1.0.0" Blue Bird "". dbus (Список рассылки).
  23. ^ а б Молькентин, Даниэль (12 ноября 2006 г.). "D-Bus 1.0" Blue Bird "выпущен". Новости KDE. Получено 3 ноября 2015.
  24. ^ Сейго, Аарон. «Введение в D-BUS». KDE TechBase. Получено 3 ноября 2015.
  25. ^ Поэтинг, Леннарт (19 июня 2015). "Новый sd-bus API systemd". Получено 21 октября 2015. С момента создания systemd это была система IPC, в которой он предоставляет свои интерфейсы.
  26. ^ "Справочное руководство Polkit". FreeDesktop.org. Получено 3 ноября 2015.
  27. ^ «Архивная копия». Архивировано из оригинал на 2015-07-21. Получено 2015-06-16.CS1 maint: заархивированная копия как заголовок (связь)
  28. ^ "Что такое D-Bus?". FreeDesktop.org. Получено 5 января 2015. Реализация нижнего уровня не предназначена в первую очередь для использования авторами приложений. Скорее, это основа для связывания авторов и ссылка для повторных реализаций. Если вы можете это сделать, рекомендуется использовать одну из привязок или реализаций более высокого уровня.
  29. ^ «Переход на GDBus». Разработчик GNOME. Получено 21 октября 2015. dbus-glib использует эталонную реализацию libdbus, GDBus - нет. Вместо этого он полагается на потоки GIO в качестве транспортного уровня и имеет собственную реализацию для настройки и аутентификации соединения D-Bus.
  30. ^ «МАТЕ: Дорожная карта». Получено 31 января 2019.
  31. ^ Поэттинг, Леннарт (20 марта 2013 г.). "[HEADSUP] планы libsystemd-bus + kdbus". systemd-devel (Список рассылки).
  32. ^ а б Эдж, Джейк (30 мая 2013 г.). «ALS: межпроцессное взаимодействие Linux и kdbus». LWN.net. Получено 21 октября 2015.
  33. ^ Поэттинг, Леннарт (19 июня 2015 г.). "[ОБЪЯВЛЕНИЕ] systemd v221". systemd-devel (Список рассылки).
  34. ^ «Открытие KDBUS». LWN.net. 2014-01-13.
  35. ^ "Documentation / kdbus.txt (из начального набора патчей)". LWN.net. 2014-11-04.
  36. ^ Корбет, Джонатан (13 января 2014 г.). «Открытие kdbus». LWN.net. Получено 11 апреля 2014.
  37. ^ Кроа-Хартман, Грег (13 апреля 2015 г.). "[GIT PULL] kdbus для 4.1-RC1". Linux-ядро (Список рассылки).
  38. ^ Корбет, Джонатан (22 апреля 2015 г.). "Kdbuswreck". LWN.net. Получено 29 июн 2015.
  39. ^ «Основной доклад: беседа у камина с Грегом Кроа-Хартманом, сотрудником Linux Foundation». YouTube. 18 октября 2016 г.
  40. ^ "Привязки D-Bus". FreeDesktop.org. Получено 5 января 2015.

внешняя ссылка