D-Bus
Промежуточное ПО Linux
Настольная шина
Разработчик(и)Красная Шапочка
Первоначальный выпускНоябрь 2006 г .; 18 лет назад ( 2006-11 )
Стабильный релиз
1.14.10 / 1 сентября 2023 г. ; 16 месяцев назад [1] ( 2023-09-01 )
Предварительный релиз
1.15.8 / 21 августа 2023 г. ; 16 месяцев назад [2] ( 2023-08-21 )
Репозиторий
  • gitlab.freedesktop.org/dbus/dbus.git
Написано вС
Операционная системаКроссплатформенный
ПредшественникCORBA
DCOP
Тип
ЛицензияGPLv2+ или AFL  2.1 [3]
Веб-сайтwww.freedesktop.org/wiki/Software/dbus

D-Bus (сокращение от « Desktop Bus » [4] ) — это механизм промежуточного программного обеспечения, ориентированный на сообщения , который обеспечивает связь между несколькими процессами, работающими одновременно на одной машине. [5] [6] D-Bus был разработан как часть проекта freedesktop.org , инициированного разработчиком GNOME Хавоком Пеннингтоном для стандартизации служб, предоставляемых средами рабочего стола Linux, такими как GNOME и 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), изначально разработанный для замены систем взаимодействия программных компонентов , используемых в средах рабочего стола GNOME и KDE Linux ( CORBA и DCOP соответственно). [13] [14] Компоненты этих сред рабочего стола обычно распределены по многим процессам, каждый из которых предоставляет только несколько — обычно одну — служб . Эти службы могут использоваться обычными клиентскими приложениями или другими компонентами среды рабочего стола для выполнения своих задач. [15]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель объекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • библиотека связи точка-точка , реализующая протокол D-Bus для обмена сообщениями между двумя процессами. В эталонной реализации эта библиотека — libdbus . В других реализациях libdbus может быть обернута другой библиотекой более высокого уровня, языковой привязкой или полностью заменена другой автономной реализацией, которая служит той же цели. [21] Эта библиотека поддерживает только связь один-к-одному между двумя процессами. [18]
  • Процесс dbus-daemon, действующий как демон шины сообщений D-Bus. Каждый процесс, подключенный к шине, сохраняет одно соединение D-Bus с ней.
    специальный процесс-демон , который играет роль шины и к которому подключаются остальные процессы с помощью любой библиотеки связи точка-точка D-Bus. Этот процесс также известен как демон шины сообщений [ 20], поскольку он отвечает за маршрутизацию сообщений от любого процесса, подключенного к шине, к другому. В эталонной реализации эту роль выполняет dbus-daemon , который сам по себе построен на основе libdbus . Другая реализация демона шины сообщений — dbus-broker , которая построена на основе sd-bus .

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

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

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

Два процесса могут использовать соединение D-Bus для прямого обмена сообщениями между собой, [22] но это не тот способ, которым обычно предполагается использовать D-Bus. Обычный способ — всегда использовать демон шины сообщений (т. е. dbus -daemon ) в качестве центральной точки связи, с которой каждый процесс должен установить свое соединение D-Bus «точка-точка». Когда процесс — клиент или служба — отправляет сообщение D-Bus, процесс шины сообщений получает его в первую очередь и доставляет соответствующему получателю. Демон шины сообщений можно рассматривать как концентратор или маршрутизатор, отвечающий за доставку каждого сообщения к месту назначения путем его повторения через соединение D-Bus с процессом-получателем. [18] Процесс-получатель определяется именем шины назначения в поле заголовка сообщения, [17] или информацией о подписке на сигналы, поддерживаемой демоном шины сообщений в случае сообщений о распространении сигналов. [6] Демон шины сообщений также может создавать свои собственные сообщения в ответ на определенные условия, такие как сообщение об ошибке для процесса, который отправил сообщение на несуществующее имя шины. [18]

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

История и принятие

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

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

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

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

Использование D-Bus неуклонно расширяется за пределы первоначальной сферы настольных сред, охватывая все большее количество системных служб. Например, сетевой демон NetworkManager , стек Bluetooth BlueZ и звуковой сервер PulseAudio используют D-Bus для предоставления части или всех своих служб. systemd использует протокол проводов D-Bus для связи между systemctl и systemd, а также продвигает традиционные системные демоны в службы D-Bus, такие как logind . [27] Другим активным пользователем D-Bus является Polkit , чей демон полномочий политики реализован как служба, подключенная к системной шине. [28]

Реализации

libdbus

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

GDBus

GDBus [9] — это реализация D-Bus на основе потоков GIO , включённых в GLib , предназначенная для использования в GTK+ и GNOME . GDBus — это не оболочка libdbus, а полная и независимая переработка спецификации и протокола D-Bus. [30] MATE Desktop [31] и Xfce (версия 4.14), которые также основаны на GTK+ 3, также используют GDBus. [ требуется ссылка ]

sd-шина

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

kdbus

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

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

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

Было разработано несколько привязок к языкам программирования для D-Bus, [41] например, для Java , C# , Ruby , Rust и Perl . [ требуется ссылка ]

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

Ссылки

  1. ^ "D-Bus 1.14.x changelog" . Получено 30 декабря 2023 г. .
  2. ^ "Файл NEWS для текущей ветки" . Получено 30 декабря 2023 г.
  3. ^ Блог Havoc, июль 2007 г.
  4. ^ Уорд, Брайан (2004). "14: Краткий обзор рабочего стола Linux". Как работает Linux: что должен знать каждый суперпользователь (2-е изд.). Сан-Франциско: No Starch Press (опубликовано в 2014 г.). стр. 305. ISBN 9781593275679. Получено 2016-11-07 . Одной из важнейших разработок, появившихся в Linux Desktop, является Desktop Bus (D-Bus), система передачи сообщений. D-Bus важна, поскольку она служит механизмом межпроцессного взаимодействия, который позволяет настольным приложениям общаться друг с другом [...].
  5. ^ abcdefghijklmnopqrstu Vermeulen, Jeroen (14 июля 2013 г.). «Введение в D-Bus». FreeDesktop.org . Проверено 22 октября 2015 г.
  6. ^ abcdefghijklmnopqrst Cocagne, Tom (август 2012 г.). "DBus Overview". pythonhosted.org . Получено 22 октября 2015 г. .
  7. ^ Вермёлен, Йерун (14 июля 2013 г.). «Введение в D-Bus». FreeDesktop.org . Получено 3 октября 2015 г. D -Bus [...] предназначен для использования в качестве единого промежуточного уровня под основными бесплатными средами рабочего стола.
  8. ^ abc Palmieri, John (январь 2005 г.). "Get on D-BUS". Red Hat Magazine. Архивировано из оригинала 23 октября 2015 г. Получено 3 ноября 2015 г.
  9. ^ ab "gdbus". Разработчик GNOME . Получено 4 января 2015 г.
  10. ^ "Модуль QtDBus". Проект Qt . Получено 1 июня 2015 г.
  11. ^ "DBus-Java Documentation". FreeDesktop.org . Получено 4 января 2015 г. .
  12. ^ Poettering, Lennart (19 июня 2015 г.). "Новый API sd-bus в systemd" . Получено 21 октября 2015 г.
  13. ^ Pennington, Havoc; Wheeler, David; Walters, Colin. "D-Bus Tutorial" . Получено 21 октября 2015 г. Для использования в сеансе рабочего стола рабочие столы GNOME и KDE имеют значительный предыдущий опыт работы с различными решениями IPC, такими как CORBA и DCOP. D-Bus создан на основе этого опыта и тщательно адаптирован для удовлетворения потребностей этих проектов рабочего стола в частности.
  14. ^ Vermeulen, Jeroen (14 июля 2013 г.). "Введение в D-Bus". FreeDesktop.org . Получено 3 октября 2015 г. D -Bus был впервые создан для замены модели компонентов типа CORBA, лежащей в основе среды рабочего стола GNOME. Подобно DCOP (используемой KDE), D-Bus должен стать стандартным компонентом основных свободных сред рабочего стола для GNU/Linux и других платформ.
  15. ^ "Desktop Environment - an Overview | ScienceDirect Topics". www.sciencedirect.com . Получено 24.08.2023 .
  16. ^ Ответ 7. "D-Bus FAQ" . Получено 2024-08-06 .
  17. ^ abcdefghijklm Пеннингтон, Хаос; Карлссон, Андерс; Ларссон, Александр; Герцберг, Свен; МакВитти, Саймон; Цойтен, Дэвид. «Спецификация D-шины». Freedesktop.org . Проверено 22 октября 2015 г.
  18. ^ abcdefghijklmnopqrstu vwxyz aa ab ac ad ae af ag ah ai Пеннингтон, Хавок; Уиллер, Дэвид; Уолтерс, Колин. "Учебник по D-Bus" . Получено 21 октября 2015 г.
  19. ^ Poettering, Lennart (19 июня 2015 г.). "Новый API sd-bus в systemd" . Получено 21 октября 2015 г. Мы работаем над тем, чтобы перенести все на настоящую пользовательскую шину, которая будет только одна на пользователя в системе, независимо от того, сколько раз этот пользователь войдет в систему.
  20. ^ ab Love, Robert (5 января 2005 г.). «Get on the D-BUS». Linux Journal . Получено 14 октября 2014 г.
  21. ^ "Что такое D-Bus?". FreeDesktop.org . Получено 29 октября 2015 г. Существуют также некоторые повторные реализации протокола D-Bus для таких языков, как C#, Java и Ruby. Они не используют эталонную реализацию libdbus
  22. ^ ab "Что такое D-Bus?". FreeDesktop.org . Получено 29 октября 2015 г. . построен на основе общей структуры передачи сообщений "один к одному", которая может использоваться любыми двумя приложениями для прямого взаимодействия (без использования демона шины сообщений)
  23. ^ "Активация системы D-BUS". FreeDesktop.org . Получено 18 февраля 2016 г. .
  24. ↑ Палмиери, Джон (9 ноября 2006 г.). "[объявление] о выпуске D-Bus 1.0.0 "Blue Bird"". dbus (список рассылки).
  25. ^ ab Molkentin, Daniel (12 ноября 2006 г.). "D-Bus 1.0 "Blue Bird" Released". Новости KDE . Получено 3 ноября 2015 г.
  26. ^ Сейго, Аарон. «Введение в D-BUS». Техническая база KDE . Проверено 3 ноября 2015 г.
  27. ^ Poettering, Lennart (19 июня 2015 г.). "Новый API sd-bus systemd" . Получено 21 октября 2015 г. С момента создания systemd это была система IPC, в которой он предоставлял свои интерфейсы.
  28. ^ "Справочное руководство Polkit". FreeDesktop.org . Получено 3 ноября 2015 г. .
  29. ^ "Что такое D-Bus?". FreeDesktop.org . Получено 5 января 2015 г. Реализация низкого уровня изначально не предназначена для использования авторами приложений. Скорее, это основа для связывания авторов и ссылка для повторных реализаций. Если вы можете это сделать, рекомендуется использовать одну из привязок или реализаций более высокого уровня.
  30. ^ "Переход на GDBus". Разработчик GNOME . Получено 21 октября 2015 г. dbus -glib использует реализацию ссылки libdbus, GDBus — нет. Вместо этого он полагается на потоки GIO в качестве транспортного уровня и имеет собственную реализацию для настройки соединения D-Bus и аутентификации.
  31. ^ "MATE: Roadmap". Архивировано из оригинала 29 июля 2019 года . Получено 31 января 2019 года .
  32. ↑ Poettering, Lennart (20 марта 2013 г.). "[HEADSUP] libsystemd-bus + kdbus plans". systemd-devel (список рассылки).
  33. ^ ab Edge, Jake (30 мая 2013 г.). "ALS: Linux inter-process communication and kdbus". LWN.net . Получено 21 октября 2015 г. .
  34. ↑ Poettering, Lennart (19 июня 2015 г.). "[АНОНС] systemd v221". systemd-devel (список рассылки).
  35. ^ "Открытие kdbus". LWN.net . 2014-01-13.
  36. ^ "Documentation/kdbus.txt (из первоначального набора исправлений)". LWN.net . 2014-11-04.
  37. ^ Корбет, Джонатан (13 января 2014 г.). «Раскрытие kdbus». LWN.net . Получено 11 апреля 2014 г.
  38. ^ Кроа-Хартман, Грег (13 апреля 2015 г.). "[GIT PULL] kdbus для 4.1-rc1". linux-kernel (список рассылки).
  39. ↑ Корбет, Джонатан (22 апреля 2015 г.). «Крушение автобуса kd». LWN.net . Получено 29 июня 2015 г.
  40. ^ "Основной доклад: Беседа у камина с Грегом Кроа-Хартманом, членом Linux Foundation". YouTube . 18 октября 2016 г. Архивировано из оригинала 21.12.2021.
  41. ^ "D-Bus Bindings". FreeDesktop.org . Получено 5 января 2015 г. .
  • Домашняя страница D-Bus на Freedesktop.org
  • Спецификация D-Bus
  • Введение в D-Bus на вики Freedesktop.org
  • Учебное пособие по D-Bus
  • Обзор DBus
Взято с "https://en.wikipedia.org/w/index.php?title=D-Bus&oldid=1268034697"