私が反転したときlibdevmapper.hデバイスマッパーioctlを正しく使用する方法（または代わりにlibdevmapperを使用する方法）の手がかり、コードがここにある理由が混乱しています。木の作成/管理そしてハッシュテーブル。
libdevmapperがデフォルトのデバイスマッパーioctlへのインターフェースを提供している場合、ここにデータ構造を含める動機は何ですか？さらに、カーネルがすでにすべてのデバイスマッピングを管理するためのデータ構造を持っている場合、抽象的なライブラリレベルのデータ構造は、せいぜい実際の情報のキャッシュされたバージョンです。
私は最初にデバイスマッパー、カーネルコード、システムコールに触れることに注意してください。私がここで何を見逃しているのでしょうか？
答え1
これは非常に一般的な答えです。私は対応するヘッダファイルを読んでいないことを認めます。 （詳細なコード質問をしたい場合は、スタックオーバーフロー正しい場所です。 )
データ構造がプログラム（または同じプログラムの他の部分）が通信する方法であることを無視しているようです。通信の各当事者はデータ構造を理解する必要があります。そうでなければ、メッセージを理解するのは難しいでしょう。
たとえば、カーネルのstruct stat一部のヘッダーファイルのどこかに定義があります。あなたのプログラムには、glibcが提供する他のヘッダーのヘッダーもあります（カーネルからコピーすることもできます）。ファイル情報を取得するためにシステムコールを使用すると、statそれをカーネルに渡しますstruct stat。カーネルはそのデータ構造を情報で埋めます。その後、プログラムはこの情報を読み取ります。プログラムはデータ構造を使用してカーネルと通信します。
別の例として、struct stat *プログラムの他の関数（例えば、表示を担当する関数）にそれを渡すと、プログラムはデータ構造を使用してそれ自体の2つの部分間で通信します。
したがって、libdevmapper のツリーおよびハッシュテーブルの実装と、通常、カーネル関数ライブラリヘッダのデータ構造は、いくつかの目的のうちの 1 つ以上を提供します。
- これはライブラリがカーネルと通信する方法です。
- これはライブラリがプログラムと通信する方法です。
- ライブラリ開発者は、ライブラリがプログラムに役立つと考えており（devmapperの状態を追跡するなど）、小さすぎたり大きすぎたりせずに含めることができるほど密接に関連していると思います。