D-Bus

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
D-Bus
開発者Red Hat
初回リリース2006年11月; 15年前 (2006-11
安定リリース
1.12.20 / 2020年7月2日; 19か月前[1] (2020-07-02)
プレビューリリース
1.13.18 / 2020年7月2日; 19か月前[2] (2020-07-02)
リポジトリ
で書かれているC
オペレーティング・システムクロスプラットフォーム
タイプ
ライセンスGPLv2 +またはAFL2.1  [ 3]
Webサイトwww .freedesktop .org / wiki / Software / dbus

コンピューティングにおいて、D-Bus (「 DesktopBus[4]の略)は、同じマシン上で同時に実行されている複数のプロセス間の通信を可能にするメッセージ指向ミドルウェアメカニズムです。[5] [6] D-Busは、 GNOMEKDEなどのLinuxデスクトップ環境によって提供されるサービスを標準化するためにRedHatHavocPenningtonによって開始されたfreedesktop.orgプロジェクトの一部として開発されました。[7] [8] [デッドリンク]

freedesktop.orgプロジェクトは、仕様のリファレンス実装として、libdbusと呼ばれる無料のオープンソースソフトウェアライブラリも開発しました。GDBus(GNOME)、 [9] QtDBus(Qt / KDE)、[10] dbus-java [11]など、D-Bus仕様の他の実装も存在するため、このライブラリをD-Bus自体と混同しないでください。およびsd-bus(systemdの一部)。[12]

概要

D-Busは、 GNOMEおよびKDE Linuxデスクトップ環境(それぞれCORBAおよびDCOP )で使用されるソフトウェアコンポーネント通信システムを置き換えるために最初に設計されたプロセス間通信(IPC)メカニズムです。[13] [14]これらのデスクトップ環境のコンポーネントは通常、多くのプロセスに分散されており、各プロセスは少数の(通常は1つの)サービスのみを提供します。これらのサービスは、通常のクライアントアプリケーションまたはデスクトップ環境の他のコンポーネントがタスクを実行するために使用できます。

D-Busを使用しないプロセス
D-Busを使用しないプロセス
D-Busを使用したプロセス
D-Busと同じプロセス
協調するプロセスの大規模なグループは、それらの間に(1対1のIPCメソッドを使用して)個々の通信チャネルの密なメッシュを必要とします。D-Busは、単一の共有チャネルでIPC要件を簡素化します。

関係するプロセスの数が多いため(サービスを提供するプロセスとそれらにアクセスするクライアントを合計する)、それらすべての間で1対1のIPC通信を確立することは、非効率的で非常に信頼性の低い[要出典]アプローチになります。代わりに、D-Busは、単一の共有仮想チャネルを介してプロセスのグループ間のすべての通信を収集するソフトウェアバスの 抽象化を提供します。[6]バスに接続されたプロセスは、バスが内部でどのように実装されているかを知りませんが、D-Bus仕様は、バスに接続されたすべてのプロセスがバスを介して相互に通信できることを保証します。

Linuxデスクトップ環境は、特に次のように複数のバスをインスタンス化することにより、D-Bus機能を利用します。[15] [6] [16]

  • システムのすべてのユーザーとプロセスが利用できる単一のシステムバスで、システムサービス(つまり、オペレーティングシステムと任意のシステムデーモンによって提供されるサービス)へのアクセスを提供します。
  • 各ユーザーログインセッションのセッションバス。同じデスクトップセッションでユーザーアプリケーションにデスクトップサービスを提供し、デスクトップセッション全体の統合を可能にします。

プロセスは、バスへのアクセスが許可されていれば、任意の数のバスに接続できます。実際には、これは、すべてのユーザープロセスがシステムバスとその現在のセッションバスに接続できることを意味しますが、別のユーザーのセッションバス、または同じユーザーが所有する別のセッションバスに接続することはできません。後者の制限は、すべてのユーザーセッションが単一のユーザーバスに結合された場合、将来変更される可能性があります。[17]

D-Busは、情報共有、モジュール性、特権分離など、アプリケーションに追加または既存の機能を簡素化しますたとえば、BluetoothまたはSkypeを介して受信した着信音声通話に関する情報は、現在実行中の音楽プレーヤーによって伝播および解釈できます。音楽プレーヤーは、音量をミュートするか、通話が終了するまで再生を一時停止することで対応できます。[18]

D-Busは、ユーザーアプリケーションのさまざまなコンポーネントを統合するためのフレームワークとしても使用できます。たとえば、オフィススイートはセッションバスを介して通信し、ワードプロセッサスプレッドシートの間でデータを共有できます。

D-Bus仕様

バスモデル

バスへのすべての接続は、D-Busのコンテキストでは、いわゆるバス名によって識別されます。[5]バス名は、ドットで区切られた2つ以上の文字、数字、ダッシュ、およびアンダースコアの文字列で構成されます。有効なバス名の例はですorg.freedesktop.NetworkManager[6]

プロセスがバスへの接続を設定すると、バスは接続に一意の接続名と呼ばれる特別なバス名を割り当てます。[16] [6]このタイプのバス名は不変であり、接続が存在する限り変更されないことが保証されています。さらに重要なことに、バスの存続期間中は再利用できません。[5] [16] [6]これは、同じプロセスがバスへの接続を閉じて新しい接続を作成した場合でも、そのバスへの他の接続がそのような一意の接続名を割り当てることはないことを意味します。一意の接続名は、コロン文字で始まるため、簡単に識別できます。[16] [6]一意の接続名の例は次のとおりです。:1.1553(コロンの後の文字には特別な意味はありません[16])。

プロセスは、接続のために追加のバス名を要求できます[16]。ただし、要求された名前がバスへの別の接続によってまだ使用されていない場合に限ります。D-Busの用語では、バス名が接続に割り当てられている場合、その接続がバス名を所有していると言われます。[5] [16]その意味で、バス名を2つの接続で同時に所有することはできませんが、一意の接続名とは異なり、これらの名前は、使用可能な場合は再利用できます。プロセスはバス名を再利用できます。別のプロセスによって(意図的かどうかにかかわらず)リリースされます。[5] [6]

これらの追加のバス名(一般に既知の名前と呼ばれる)の背後にある考え方は、事前に設定されたバス名を使用してサービスを参照する方法を提供することです。[16] [6]たとえば、システムバスの現在の時刻と日付を報告するサービスは、プロセスに関係なく、接続がorg.freedesktop.timedate1バス名を所有するプロセスにあります。

バス名は、単一インスタンスアプリケーションを実装する簡単な方法として使用できます(2番目のインスタンスは、バス名がすでに使用されていることを検出します)。[16]プロセスの終了によりバス名が解放されたときにバスが通知を送信するため、サービスプロセスのライフサイクルを追跡するためにも使用できます。[16]

オブジェクトモデル

D-Busは、いくつかのコンポーネント指向通信システムの代替としての当初の概念により、クライアントとサービス間の通信のセマンティクスを表現するためのオブジェクトモデルを前任者と共有しています。D-Busオブジェクトモデルで使用される用語は、一部のオブジェクト指向 プログラミング言語で使用される用語を模倣していますこれは、D-Busが何らかの形でOOP言語に限定されていることを意味するものではありません。実際、最もよく使用される実装(libdbus)は手続き型プログラミング言語 であるCで記述されています。

D-Feetを使用して、D-Busバス内の既存のバス名、オブジェクト、インターフェイス、メソッド、および信号を参照する

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オブジェクトは複数のインターフェースを実装できますが、少なくとも1つを実装する必要があり、それによって定義されるすべてのメソッドとシグナルをサポートします。オブジェクトによって実装されるすべてのインターフェースの組み合わせは、オブジェクトと呼ばれますタイプ[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は、独自のタイプ定義システムと独自のマーシャリングを備えた、従来のIPCメカニズムよりもRPCメカニズムに近いです。[5]

D-Busを介してメソッドを呼び出すための1対1の要求/応答メッセージ交換の例。ここで、クライアントプロセスは、バス内のorg.example.foo(または)という名前のサービスプロセスから/ org / example / object1オブジェクトのSetFoo()メソッドを呼び出します:1.14

バスは、クライアントとサービスプロセス間でメッセージを交換する2つのモードをサポートしています[5]

  • 1対1の要求/応答:これは、クライアントがオブジェクトのメソッドを呼び出すための方法です。クライアントはオブジェクトをエクスポートするサービスプロセスにメッセージを送信し、サービスはクライアントプロセスにメッセージを返します。[16]クライアントによって送信されるメッセージには、オブジェクトパス、呼び出されたメソッドの名前(およびオプションでそのインターフェイスの名前)、およびオブジェクトの選択されたインターフェイスによって定義された入力パラメータの値(存在する場合)が含まれている必要があります。応答メッセージには、オブジェクトのメソッド呼び出しによって返される出力パラメーターの値や、エラーが発生した場合の例外情報など、要求の結果が含まれます。[5] [16]
  • パブリッシュ/サブスクライブ:これは、オブジェクトがシグナルの発生を関係者に通知するための方法です。オブジェクトのサービスプロセスは、バスがオブジェクトの信号にサブスクライブされている接続されたクライアントにのみ通過するというメッセージをブロードキャストします。[16]メッセージには、オブジェクトパス、シグナルの名前、シグナルが属するインターフェイス、およびシグナルのパラメーターの値(存在する場合)が含まれます。通信は一方向です。送信者は受信者のIDも数も知らないため、クライアントプロセスからの元のメッセージに対する応答メッセージはありません。[5] [16]

すべてのD-Busメッセージは、ヘッダーと本文で構成されています。[16]ヘッダーは、メッセージのタイプ、送信者、およびメッセージを受信者に配信するために必要な情報(宛先バス名、オブジェクトパス、メソッドまたはシグナル名、インターフェイス名など)を識別するいくつかのフィールドで構成されます。 )。[16] [15]本文には、レシーバープロセスが解釈するデータペイロード(たとえば、入力引数または出力引数)が含まれています。すべてのデータは、整数や浮動小数点数、文字列、複合型などのさまざまな型のシリアル化をサポートするワイヤー形式と呼ばれるよく知られたバイナリ形式でエンコードされます[15] 。マーシャリングとも呼ばれ ます。

D-Bus仕様は、ワイヤープロトコル、つまりD-Bus接続内のプロセス間で交換されるD-Busメッセージを作成する方法を定義します。ただし、これらのメッセージを配信するための基本的なトランスポート方法は定義されていません。

内部

ほとんどの既存のD-Bus実装は、リファレンス実装のアーキテクチャに従います。このアーキテクチャは、2つの主要なコンポーネントで構成されています。[5]

  • 2つのプロセス間でメッセージを交換するためにD-Busワイヤープロトコルを実装するポイントツーポイント通信ライブラリ。リファレンス実装では、このライブラリはlibdbusです。他の実装では、 libdbusは別の高レベルのライブラリ、言語バインディングによってラップされるか、同じ目的を果たす別のスタンドアロン実装によって完全に置き換えられる場合があります。[19]このライブラリは、2つのプロセス間の1対1の通信のみをサポートします。[16]
  • D-Busメッセージバスデーモンとして機能するdbus-daemonプロセス。バスに接続されているすべてのプロセスは、1つのD-Bus接続を維持します。
    バスの役割を果たし、残りのプロセスがD-Busポイントツーポイント通信ライブラリを使用して接続する特別なデーモンプロセス。このプロセスは、バスに接続されているプロセスから別のプロセスへのメッセージのルーティングを担当するためメッセージバスデーモン[18]とも呼ばれます。リファレンス実装では、この役割はdbus-daemonによって実行されます。dbus -daemon自体はlibdbusの上に構築されています。メッセージバスデーモンの別の実装は、sd-busの上に構築されたdbus-brokerです。
プロセスAとBは、Unixドメインソケットを介してそれらの間に1対1のD-Bus接続を持っています
プロセスAとBは、Unixドメインソケットを介してlibdbusを使用して1対1のD-Bus接続を確立します。彼らはそれを使ってメッセージを直接交換することができます。[20]このシナリオでは、バス名は必要ありません。[16]
プロセスAとBは、Unixドメインソケットを介したdbus-daemonプロセスとの1対1のD-Bus接続を備えています。
プロセスAとBはどちらも、Unixドメインソケットを介してlibdbusを使用してdbusデーモンに接続されています。彼らはメッセージを交換してメッセージバスプロセスに送信することができ、メッセージバスプロセスはメッセージを適切なプロセスに配信します。このシナリオでは、宛先プロセスを識別するためにバス名が必須です。

libdbusライブラリ(または同等のもの)は、内部でネイティブの低レベルIPCメカニズムを使用して、D-Bus接続の両端にある2つのプロセス間で必要なD-Busメッセージを転送します。D-Bus仕様では、サポートするトランスポート方法を決定するのは通信ライブラリであるため、どの特定のIPCトランスポートメカニズムを使用できるかを義務付けていません。たとえば、LinuxなどのUnixライクなオペレーティングシステムでは、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は、提供するバスインスタンスごとに異なるバスアドレスを定義します。これらのアドレスは、デーモンの構成ファイルで定義されています。

2つのプロセスはD-Bus接続を使用して、それらの間で直接メッセージを交換できます[20]が、これはD-Busが通常使用されることを意図した方法ではありません。通常の方法は、各プロセスがポイントツーポイントのD-Bus接続を確立する必要がある通信の中心点として、常にメッセージバスデーモン(つまり、dbus-daemon )を使用することです。プロセス(クライアントまたはサービス)がD-Busメッセージを送信すると、メッセージバスプロセスは最初にそれを受信し、適切な受信者に配信します。メッセージバスデーモンは、受信者プロセスへのD-Bus接続を介してメッセージを繰り返すことにより、各メッセージを宛先に到達させることを担当するハブまたはルーターと見なすことができます。[16]受信者プロセスは、メッセージのヘッダーフィールドの宛先バス名[15]によって、または信号伝播メッセージの場合はメッセージバスデーモンによって維持される信号へのサブスクリプション情報によって決定されます。[6]メッセージバスデーモンは、存在しないバス名にメッセージを送信したプロセスへのエラーメッセージなど、特定の条件への応答として独自のメッセージを生成することもできます。[16]

dbus-daemonは、D-Bus自体によってすでに提供されている機能セットを追加機能で改善します。たとえば、サービスのアクティブ化により、必要に応じて、つまりそのようなサービスのバス名への最初の要求がメッセージバスデーモンに到着したときに、サービスを自動的に開始できます。[5]このように、サービスプロセスは、システムの初期化またはユーザーの初期化の段階で起動する必要も、使用されていないときにメモリやその他のリソースを消費する必要もありません。この機能は元々 setuidヘルパー[21]を使用して実装されていましたが、現在ではsystemdのサービスアクティベーションフレームワークによって提供することもできます。[要出典]サービスのアクティブ化は、サービスのプロセスライフサイクルの管理を容易にする重要な機能です(たとえば、デスクトップコンポーネントをいつ開始または停止する必要があるか)。[16]

歴史と養子縁組

D-Busは、2002年にHavoc Pennington、Alex Larsson(Red Hat)、AndersCarlssonによって開始されました。[8]バージョン1.0(API安定版と見なされます)は2006年11月にリリースされました。[22] [23]

dbus-daemonは、最新のLinuxグラフィカルデスクトップ環境で重要な役割を果たします

KDEのバージョン2および3で使用されているDCOPシステムの影響を強く受けた、D-BusはKDE4リリースでDCOPに取って代わりました。[23] [24] D-Busの実装は、ほとんどのPOSIXオペレーティングシステムをサポートしており、Windows用のポートが存在します。これは、Qt4以降のGNOMEで使用されます。GNOMEでは、以前のBonoboメカニズムのほとんどの部分が徐々に置き換えられています。Xfceでも使用されます。

以前の採用者の1つは、(現在は非推奨の)ハードウェアアブストラクションレイヤーでした。HALは、D-Busを使用して、コンピューターに追加またはコンピューターから削除されたハードウェアに関する情報をエクスポートしました。[8]

D-Busの使用は、デスクトップ環境の当初の範囲を超えて着実に拡大しており、ますます多くのシステムサービスをカバーしています。たとえば、NetworkManagerネットワークデーモン、BlueZ bluetoothスタック、PulseAudioサウンドサーバーは、D-Busを使用してサービスの一部またはすべてを提供します。systemdは、 systemctlとsystemd間の通信にD-Busワイヤープロトコルを使用し、logindなどの従来のシステムデーモンをD-Busサービスに昇格させています。[25] D-Busのもう1つのヘビーユーザーは、システムバスに接続されたサービスとしてポリシーオーソリティデーモンが実装されているPolkitです。[26]

実装

libdbus

D-Busにはいくつかの実装がありますが、最も広く使用されているのは、仕様を設計したのと同じfreedesktop.orgプロジェクトによって開発されたリファレンス実装libdbusです。ただし、libdbusは低レベルの実装であり、アプリケーション開発者が直接使用することを意図したものではなく、D-Busの他の再実装(デスクトップ環境の標準ライブラリやプログラミング言語バインディングに含まれるものなど)のリファレンスガイドとして使用されます。 )。freedesktop.orgプロジェクト自体は、代わりに「より高いレベルのバインディングまたは実装の1つを使用する」ことをアプリケーション作成者に推奨しています。[27]最も使用されているD-Busの実装としてlibdbusが優勢であるため、「D-Bus」と「libdbus」という用語はしばしば同じ意味で使用され、混乱を招きました。

GDBus

GDBus [9]は、 GLibに含まれるGIOストリームに基づくD-Busの実装であり、 GTK +およびGNOMEでの使用を目的としていますGDBusはlibdbusのラッパーではありませんが、D-Busの仕様とプロトコルの完全で独立した再実装です。[28] MATE Desktop [29]およびXfce(バージョン4.14)もGTK + 3に基づいており、GDBusも使用します。

QtDBus

QtDBus [10]は、バージョン4.2以降のQtライブラリに含まれているD-Busの実装です。このコンポーネントは、システムで利用可能なD-Busサービスにアクセスするために、 KDEアプリケーション、ライブラリ、およびコンポーネントによって使用されます。

sd-bus

2013年、systemdプロジェクトはコードを簡素化するためにlibdbusを書き直しましたが[30]、D-Bus全体のパフォーマンスも大幅に向上しました。予備的なベンチマークで、BMWはsystemdのD-Busライブラリがパフォーマンスを360%向上させることを発見しました。[31] systemdのバージョン221までに、sd- busAPIは安定していると宣言されました。[32]

libnih-dbus

libnihプロジェクトは、D-BusのCサポートの軽量な「標準ライブラリ」を提供します。さらに、クロスコンパイルを適切にサポートします。

kdbus

kdbusは、キャラクターデバイスドライバーとして実装されています。[33] [34]/dev/kdbusプロセス間のすべての通信は、 (devfsを参照)の特殊文字デバイスノードを介して行われます

kdbusは、カーネルを介したピアツーピアのプロセス間通信メカニズムとしてD-Busを再実装することを目的としたプロジェクトでした。パフォーマンスの向上に加えて、kdbusには、名前空間や監査などの他のLinuxカーネル機能から生じる利点があります。 [31] [35]カーネルの仲介、競合状態の解消、および起動時とシャットダウン時のD-Busの使用によるセキュリティ( systemdで必要)。Linuxカーネルにkdbusを含めることは議論の余地があり[37] より一般的なプロセス間通信としてBUS1を支持するようになりました[38]

zbus

zbusは、D-Bus用のネイティブRustライブラリです。その主な強みは、サービスとの通信とサービスの実装を非常に簡単かつシンプルにする マクロです。

言語バインディング

JavaC#Rubyなど、D-Bus用のプログラミング言語バインディングがいくつか開発されています[39]

も参照してください

参考文献

  1. ^ 「D-Bus1.12.x変更ログ」2018年8月5日取得
  2. ^ 「現在のブランチのNEWSファイル」2018年11月14日取得
  3. ^ Havocのブログ2007年7月
  4. ^ ワード、ブライアン(2004)。「14:Linuxデスクトップの簡単な調査」。Linuxのしくみ:すべてのスーパーユーザーが知っておくべきこと(2版)。サンフランシスコ:ノースターチプレス(2014年発行)。p。305. ISBN  97815932756792016年11月7日取得Linuxデスクトップから生まれる最も重要な開発の1つは、メッセージパッシングシステムであるデスクトップバス(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 Vermeulen、Jeroen(2013年7月14日)。「D-Busの紹介」FreeDesktop.org 2015年10月22日取得
  6. ^ a b c d e f g h i j k l m n o p q r s t コカーニュ、トム(2012年8月)。「DBusの概要」pythonhosted.org 2015年10月22日取得
  7. ^ Vermeulen、Jeroen(2013年7月14日)。「D-Busの紹介」FreeDesktop.org 2015年10月3日取得D-Bus [...]は、メインの無料デスクトップ環境の下にある統合ミドルウェアレイヤーとして使用するように設計されています。
  8. ^ a b c パルミエリ、ジョン(2005年1月)。「D-BUSに乗る」Red HatMagazine。2015年10月23日にオリジナルからアーカイブされました2015年11月3日取得
  9. ^ a b "gdbus"GNOME開発者2015年1月4日取得
  10. ^ a b "QtDBusモジュール"Qtプロジェクト2015年6月1日取得
  11. ^ 「DBus-Javaドキュメント」FreeDesktop.org 2015年1月4日取得
  12. ^ ポッターリング、レナート(2015年6月19日)。「systemdの新しいsd-busAPI」2015年10月21日取得
  13. ^ ペニントン、ハボック; ウィーラー、デビッド; ウォルターズ、コリン。「D-Busチュートリアル」2015年10月21日取得デスクトップセッション内のユースケースの場合、GNOMEおよびKDEデスクトップには、CORBAやDCOPなどのさまざまなIPCソリューションに関する重要な経験があります。D-Busはその経験に基づいて構築されており、特にこれらのデスクトッププロジェクトのニーズを満たすように注意深く調整されています。
  14. ^ Vermeulen、Jeroen(2013年7月14日)。「D-Busの紹介」FreeDesktop.org 2015年10月3日取得D-Busは、GNOMEデスクトップ環境の基盤となるCORBAのようなコンポーネントモデルを置き換えるために最初に構築されました。DCOP(KDEで使用される)と同様に、D-BusはGNU / Linuxおよびその他のプラットフォームの主要な無料デスクトップ環境の標準コンポーネントになるように設定されています。
  15. ^ a b c d e f g h i j k l m Pennington、Havoc; カールソン、アンダース; ラーソン、アレクサンダー; ハーズバーグ、スヴェン; McVittie、Simon; ツォイテン、デビッド。「D-Bus仕様」Freedesktop.org 2015年10月22日取得
  16. ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai Pennington、Havoc; ウィーラー、デビッド; ウォルターズ、コリン。「D-Busチュートリアル」2015年10月21日取得
  17. ^ ポッターリング、レナート(2015年6月19日)。「systemdの新しいsd-busAPI」2015年10月21日取得私たちは、ユーザーがログインする回数に関係なく、システム上のユーザーごとに1つしかない真のユーザーバスに物事を移動することに取り組んでいます。
  18. ^ a b 愛、ロバート(2005年1月5日)。「D-BUSに乗る」LinuxJournal2014年10月14日取得
  19. ^ 「D-Busとは何ですか?」FreeDesktop.org 2015年10月29日取得C#、Java、Rubyなどの言語用のD-Busプロトコルの再実装もいくつかあります。これらはlibdbusリファレンス実装を使用しません
  20. ^ a b 「D-Busとは?」FreeDesktop.org 2015年10月29日取得一般的な1対1のメッセージパッシングフレームワークの上に構築されており、任意の2つのアプリが直接通信するために使用できます(メッセージバスデーモンを経由せずに)
  21. ^ 「D-BUSシステムアクティベーション」FreeDesktop.org 2016年2月18日取得
  22. ^ パルミエリ、ジョン(2006年11月9日)。「【発表】D-Bus1.0.0「BlueBird」発売」dbus(メーリングリスト)。
  23. ^ a b モルケンティン、ダニエル(2006年11月12日)。「D-Bus1.0「ブルーバード」発売」KDEニュース2015年11月3日取得
  24. ^ セイゴ、アーロン。「D-BUSの紹介」KDETechBase 2015年11月3日取得
  25. ^ ポッターリング、レナート(2015年6月19日)。「systemdの新しいsd-busAPI」2015年10月21日取得systemdの開始以来、インターフェースを公開するのはIPCシステムでした。
  26. ^ 「Polkitリファレンスマニュアル」FreeDesktop.org 2015年11月3日取得
  27. ^ 「D-Busとは何ですか?」FreeDesktop.org 2015年1月5日取得低レベルの実装は、主にアプリケーション作成者が使用するように設計されていません。むしろ、それは著者を拘束するための基礎であり、再実装のための参照です。それが可能な場合は、より高いレベルのバインディングまたは実装の1つを使用することをお勧めします。
  28. ^ 「GDBusへの移行」GNOME開発者2015年10月21日取得dbus-glibはlibdbusリファレンス実装を使用しますが、GDBusは使用しません。代わりに、トランスポート層としてGIOストリームに依存し、D-Bus接続のセットアップと認証のための独自の実装があります。
  29. ^ 「MATE:ロードマップ」2019年1月31日取得
  30. ^ ポッターリング、レナート(2013年3月20日)。「[HEADSUP] libsystemd-bus + kdbusplans」systemd-devel(メーリングリスト)。
  31. ^ a b エッジ、ジェイク(2013年5月30日)。「ALS:Linuxプロセス間通信とkdbus」LWN.net 2015年10月21日取得
  32. ^ ポッターリング、レナート(2015年6月19日)。"[ANNOUNCE] systemdv221"systemd-devel(メーリングリスト)。
  33. ^ 「kdbusの除幕式」LWN.net2014-01-13。
  34. ^ "Documentation / kdbus.txt(初期パッチセットから)"LWN.net2014-11-04。
  35. ^ コーベット、ジョナサン(2014年1月13日)。「kdbusの除幕式」LWN.net 2014年4月11日取得
  36. ^ Kroah-Hartman、Greg(2015年4月13日)。"[GIT PULL] kdbus for4.1-rc1"linux-kernel(メーリングリスト)。
  37. ^ コーベット、ジョナサン(2015年4月22日)。「kdbuswreck」LWN.net 2015年6月29日取得
  38. ^ 「基調講演:Greg Kroah-Hartman、Linux FoundationFellowとの炉辺談話」YouTube2016年10月18日。 2021年12月21日のオリジナルからアーカイブ。
  39. ^ 「D-Busバインディング」FreeDesktop.org 2015年1月5日取得

外部リンク