デバイスドライバーのしくみを理解しようとする
私は、これまでにわかったことに基づいて、デバイスドライバーのしくみを理解しようとしています。デバイスドライバーは、オペレーティングシステムとデバイスの間の単なる「仲介者」です。デバイスドライバーの理解を示すために、次の図を作成しました。
また、アプリケーションはデバイスドライバーと直接対話できません。オペレーティングシステムのみがそれを実行できます（たとえば、アプリケーションが何かを印刷したい場合、アプリケーションはオペレーティングシステムに「通知」し、オペレーティングシステムはデバイスドライバーに通知します）。
私の理解は正しいですか？また、WindowsとmacOSのデバイスドライバーの概念はLinuxの場合と同じですか？
非常に簡単に：
デバイスドライバーについて最も重要なことは、カーネルと同じアクセス許可でカーネルスペースで実行されるため、ハードウェアに直接アクセスできることです。アプリケーションは（通常）これを行うことを許可されていません。
したがって、デバイスドライバーは、特定のハードウェア（「デバイス」）へのアクセスを整理するカーネルの一部と考えることができます。
アプリケーションは、さまざまなレベルでカーネルと対話できます。より高度な抽象化（ファイルシステムなど）から中途半端な抽象化（ブロックデバイス）まで、実際に低レベルの抽象化（/proc/または/sysの一部のファイル）など、 ioctlsデバイス内の/dev）。したがって、低レベルの対話がデバイスドライバーと直接通信する場合があります。カーネルがデバイスドライバーに呼び出しをリダイレクトするのは非常に薄いレイヤーのみです。したがって、「アプリケーションはデバイスドライバーと直接やり取りすることはできません。オペレーティングシステムのみがそれを行うことができます」は、ある種の真であり、またある種の偽です。
また、カーネルには、絵に描いたような多くの抽象化レイヤーがあります（「OSが送信するメッセージは同じであり、デバイスドライバーは異なるメッセージを使用してハードウェアと通信します。たとえば、ブロックレイヤーはUSBレイヤーは1種類のメッセージを受信しますが、別のUSBホストコントローラーを使用できます。
したがって、全体像ははるかに難しく、カーネルにはレイヤーとサブシステムがあり、ハードウェアと実際に通信するデバイスドライバーはその階層の最下部にあります。さらに混乱させるために、デバイスドライバーと他のレイヤーの両方がモジュールの形で提供されます（Linuxの場合）。 lsmodと入力すると、どのモジュールがアクティブで、どのモジュールが他のどのモジュールを使用しているかを確認できます。
また、印刷は非常に悪い例です。プリンター固有の処理のほとんどはユーザー空間で行われ、デバイスドライバーでは行われません。
Windows、Linux、MacOSはすべてこれらの原則に従っていますが、詳細は大きく異なります。
それは役に立ちますか？
編集：
Linuxでの印刷は現在、通常 cups で行われます。 Cupsには、さまざまなプリンターでドキュメントをレンダリングできるプログラムのコレクションがあります。これらのプログラムはすべて、ファイル（pdf/postscript/...としてのドキュメント）を取得し、プリンターが理解できる形式で別のファイルに変換します。これはすべて実際のハードウェアにアクセスする必要がないため、カーネルの外部で行われます。ファイルの読み取りと書き込みを行うだけです。変換されたデータがプリンターに送信されるとき、最後の部分のみがカーネルを使用します。そして、同じタイプのプリンターでも、ネットワーク経由、USB経由、シリアル接続経由など、さまざまなパスを使用できます。この最後の部分は、多くの場合プリンター固有ではありません。
そのため、Linuxには、大多数のプリンター用のプリンター固有のデバイスドライバーはありません。 （一部のプリンターでは、1つ必要になる場合があります）。
デバイスドライバーは、オペレーティングシステムとデバイス間の単なる「仲介者」です。
はい、それは多かれ少なかれそれです。
デバイスドライバーは、標準化されたプログラミング呼び出しをハードウェアコンポーネントのデバイス固有の操作に変換する「ブラックボックス」です。
このように、プログラムは特定のハードウェアの内部動作を知る必要はありません。これは、透過的な方法でマッピングを行う特定のデバイスドライバであり、プログラムがハードウェアと「通信」できるようにします。
これらはカーネルとは別に構築され、必要に応じて（カーネルにロードされたモジュールとして）アクティブ化されます。