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

В вычислении , D-Bus (сокращенно « Desktop Bus » [4] ) представляет собой сообщение-ориентированного промежуточного программного обеспечения механизм , который обеспечивает связь между несколькими процессами , работающих одновременно на одной и той же машине. [5] [6] D-Bus был разработан как часть проекта freedesktop.org , инициированного Havoc Pennington из Red Hat для стандартизации сервисов, предоставляемых средами рабочего стола 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] Компоненты этих сред рабочего стола обычно распределяются по множеству процессов, каждый из которых предоставляет лишь несколько - обычно одну - сервисов . Эти службы могут использоваться обычными клиентскими приложениями или другими компонентами среды рабочего стола для выполнения своих задач.

Те же процессы с 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/sheets/3/cells/4/5. [16] Однако это не является обязательным - но и не рекомендуется - формировать иерархии внутри путей к объектам. [6]Конкретное соглашение об именах для объектов службы полностью зависит от разработчиков такой службы, но многие разработчики предпочитают размещать их в пространстве имен, используя зарезервированное доменное имя проекта в качестве префикса (например, / org / kde ). [16]

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

Члены - методы и сигналы - которые могут использоваться с объектом, определяются интерфейсом . [16] интерфейс представляет собой набор деклараций методов ( в том числе ее прохождения и возвращающихся параметров) и сигналов ( в том числе его параметров) , идентифицированное именем , разделенные точки , напоминающем язык 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-daemon , который сам построен поверх libdbus . Другая реализация демона шины сообщений - это dbus-broker , построенный на основе sd-bus .
Процессы A и B имеют прямое соединение D-Bus с использованием libdbus через сокет домена Unix. Они могут использовать его для прямого обмена сообщениями. [20] В этом сценарии имена шины не требуются. [16]
Оба процесса A и B подключены к dbus-daemon с помощью libdbus через сокет домена Unix. Они могут обмениваться сообщениями, отправляя их процессу шины сообщений, который, в свою очередь, доставляет сообщения соответствующему процессу. В этом сценарии имена шины являются обязательными для идентификации процесса назначения.

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

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

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

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

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

История и усыновление [ править ]

D-Bus была основана в 2002 году Havoc Pennington, Алексом Ларссоном ( Red Hat ) и Андерсом Карлссоном. [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 . В GNOME он постепенно заменил большинство частей более раннего механизма Bonobo . Он также используется Xfce .

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

Использование D-Bus неуклонно расширяется за пределы первоначальной области настольных сред и охватывает все большее количество системных служб. Например, сетевой демон NetworkManager , стек Bluetooth BlueZ и звуковой сервер 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 + и GNOME . GDBus - это не оболочка libdbus, а полная и независимая реализация спецификации и протокола D-Bus. [29] MATE Desktop [30] и Xfce (версия 4.14), которые также основаны на GTK + 3, также используют GDBus.

QtDBus [ править ]

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

sd-bus [ править ]

В 2013 году проект systemd переписал libdbus в попытке упростить код [31], но это также привело к значительному увеличению общей производительности D-Bus. В предварительных тестах BMW обнаружила, что библиотека D-Bus systemd повысила производительность на 360%. [32] В версии 221 systemd API sd-bus был объявлен стабильным. [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], например, для Java , C # и Ruby .

См. Также [ править ]

  • Linux на рабочем столе
  • Общая языковая инфраструктура
  • Общая архитектура брокера объектных запросов
  • Компонентная объектная модель
  • Распределенная компонентная объектная модель
  • Интерфейс внешней функции
  • Вызов удаленного метода Java
  • Удаленный вызов процедур
  • XPCOM

Ссылки [ править ]

  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. Проверено 7 ноября 2016 . Одним из наиболее важных достижений, которые появятся на рабочем столе Linux, является шина рабочего стола (D-Bus), система передачи сообщений. D-Bus важен, потому что он служит механизмом межпроцессного взаимодействия, который позволяет настольным приложениям общаться друг с другом [...].
  5. ^ a b c d e f g h i j k l m n o p q r s t u Вермёлен, Джерун (14 июля 2013 г.). «Введение в D-Bus» . FreeDesktop.org . Проверено 22 октября 2015 года .
  6. ^ a b c d e f g h i j k l m n o p q r s t Кокань, Том (август 2012). «Обзор DBus» . pythonhosted.org . Проверено 22 октября 2015 года .
  7. ^ Vermeulen, Йерун (14 июля 2013). «Введение в D-Bus» . FreeDesktop.org . Проверено 3 октября 2015 года . D-Bus [...] разработан для использования в качестве единого промежуточного уровня под основными средами бесплатного рабочего стола.
  8. ^ a b c Palmieri, Джон (январь 2005 г.). «Садись на D-BUS» . Журнал Red Hat. Архивировано из оригинального 23 октября 2015 года . Дата обращения 3 ноября 2015 .
  9. ^ a b "gdbus" . Разработчик GNOME . Проверено 4 января 2015 года .
  10. ^ a b "Модуль 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. ^ Vermeulen, Йерун (14 июля 2013). «Введение в D-Bus» . FreeDesktop.org . Проверено 3 октября 2015 года . D-Bus был впервые создан для замены CORBA-подобной модели компонентов, лежащей в основе среды рабочего стола GNOME. Подобно DCOP (который используется KDE), D-Bus собирается стать стандартным компонентом основных бесплатных сред рабочего стола для GNU / Linux и других платформ.
  15. ^ Б с д е е г ч я J к л м Пеннингтон, Havoc; Карлссон, Андерс; Ларссон, Александр; Герцберг, Свен; МакВитти, Саймон; Цойтен, Давид. «Спецификация D-Bus» . Freedesktop.org . Проверено 22 октября 2015 года .
  16. ^ Б с д е е г ч я J к л м п о р Q R сек т у V ш х у г аа аЬ ас объявления аи аф аг ах а.и. Pennington, Havoc; Уиллер, Дэвид; Уолтерс, Колин. "Учебное пособие по D-Bus" . Проверено 21 октября 2015 года .
  17. ^ Поттеринг, Леннарт (19 июня 2015). «Новый sd-bus API systemd» . Проверено 21 октября 2015 года . мы работаем над перемещением вещей на настоящую пользовательскую шину, из которой на каждого пользователя в системе приходится только одна, независимо от того, сколько раз этот пользователь входит в систему
  18. ^ a b Любовь, Роберт (5 января 2005 г.). «Садись на D-BUS» . Linux Journal . Проверено 14 октября 2014 года .
  19. ^ "Что такое D-Bus?" . FreeDesktop.org . Проверено 29 октября 2015 года . Есть также некоторые переопределения протокола D-Bus для таких языков, как C #, Java и Ruby. Они не используют эталонную реализацию libdbus.
  20. ^ a b "Что такое D-Bus?" . FreeDesktop.org . Проверено 29 октября 2015 года . построен на основе общей структуры передачи сообщений один-к-одному, которая может использоваться любыми двумя приложениями для прямой связи (без прохождения через демон шины сообщений)
  21. ^ "Активация системы D-BUS" . FreeDesktop.org . Проверено 18 февраля +2016 .
  22. ↑ Palmieri, Джон (9 ноября 2006 г.). "[объявить] Выпущен D-Bus 1.0.0" Blue Bird "" . dbus (список рассылки).
  23. ^ a b Молькентин, Даниэль (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 . Проверено 16 июня 2015 .CS1 maint: archived copy as title (link)
  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. ^ a b Эдж, Джейк (30 мая 2013 г.). «ALS: межпроцессное взаимодействие Linux и kdbus» . LWN.net . Проверено 21 октября 2015 года .
  33. ^ Поттеринг, Леннарт (19 июня 2015). "[ОБЪЯВЛЕНИЕ] systemd v221" . systemd-devel (список рассылки).
  34. ^ "Открытие kdbus" . LWN.net . 2014-01-13.
  35. ^ "Документация / 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-kernel (список рассылки).
  38. ↑ Корбет, Джонатан (22 апреля 2015 г.). "Kdbuswreck" . LWN.net . Проверено 29 июня 2015 года .
  39. ^ "Основной доклад: Беседа у камина с Грегом Кроа-Хартманом, сотрудником Linux Foundation" . YouTube . 18 октября 2016 г.
  40. ^ "D-Bus Bindings" . FreeDesktop.org . Проверено 5 января 2015 года .

Внешние ссылки [ править ]

  • Домашняя страница D-Bus на Freedesktop.org
  • Спецификация D-Bus
  • Введение в D-Bus на вики Freedesktop.org
  • Учебное пособие по D-Bus
  • Обзор DBus