デバイスドライバとは、ＯＳの起動時にメモリ上に読み込まれて常駐し、 周辺装置からのハード的な割り込みによって駆動される、ＯＳに付属する 一種のサブルーチン群です。ＩＢＭのＰＣのマニュアルでは 「装置駆動ルーチン」などと呼ばれています（した？）。
デバイスには、以下に示すように、主に２つのタイプがあります。
ある決められた単位（ブロック）でデータの入出力を行うデバイスです。 「ファイルシステムを構成できるデバイス」と考えてください。 つまり mount(8) できるもの、ですね。
１バイトずつデータの入出力を行うデバイスです。今回の「ＳＣＳＩ ターゲット・ドライバ」はこのモデルで作りました。このドライバは、 アプリケーションがＳＣＳＩのコマンドを直接解析して動作するという、 「全く汎用性のない代物」です。
デバイスドライバは、以下に示す３つの部分から構成されます。
ＯＳの起動時に、上位（ＯＳ）から１度だけコールされる部分です。 ハードウェアの存在チェックを行った後、自分自身をデバイスドライバ としてＯＳに認識させます。
当該ドライバの場合、この初期化関数だけをグローバル関数とし、 カーネルの他の関数(/usr/src/linux/drivers/char/mem.c)から 呼ぶように mem.c を修正しました。それ以外の内部関数／変数は すべて static としました。この理由は、カーネルは膨大な オブジェクト・モジュールをリンクして作られるため、関数を グローバルにしてしまうと名前の衝突が起こり、リンクで失敗する ことが考えられるので、これを防ぐためです。
上位から（間接的に）コールされる部分です。アプリケーションが open(2) や read(2) のシステムコールを発行すると、ＯＳの デバイスドライバ・カーネル・インターフェース（ＤＫＩ）機能を 通じてＯＳから当該関数がコールされます。ＯＳからの周辺装置との 入出力要求を実行し、その結果をＯＳに返します。図示すると、
ハードウェア割り込みによって駆動される部分です。
上位アプリケーション（以下、ＡＰといいます）は、システムコールという ＯＳとのインターフェースを使ってファイル単位の入出力要求を行います。 上位ＡＰからはデバイスドライバの存在は見えません。唯一、 /dev/xxx というデバイスを仮想化したファイルが見えるだけです。上位ＡＰは、 open(2) でこのデバイス・スペシャル・ファイルをオープンします。
また、ドライバの種類によっては、デバイスドライバ・インターフェース （ＤＤＩ）という受け口を設けて、上位ＡＰからの直接的な指令を受けられる ものもあります。このような指令は、通常のＲＥＡＤ／ＷＲＩＴＥ以外の、 ドライバ内部の状態通知・設定変更を指示するものが多いです。私が作った ドライバも、ioctl(2) というＤＤＩを利用してＡＰとのやり取りを行いました。
デバイスドライバ内部では、ＯＳが提供する read(2) などのシステムコール や printf(3) などのライブラリ群（実体は libc.* にある *らしい* です） がいっさい使えません。また、上位ＡＰがまだ起動していない（＝存在しない） 状態もありうるなど、一般的なサブルーチン・ライブラリとはかなり異なった 環境を持ちます。
ＵＮＩＸシステムはマルチタスク環境であり、自分が作成したＡＰ以外に 多くのＡＰまたはデーモン（システムサービスプログラム）が動作しています。 イベント待ちを行う場合、ＤＯＳアプリケーションのようにビジーウェイト （イベントが発生するまでその場でループすること）を行うと、他のプロセス に制御が移りにくくなり、システム全体のパフォーマンスが落ちます。 このため、イベントがなかったら、スリープなどにより明示的に他のプロセス に制御を譲ってやる必要があります。このほかに、他のプロセスに制御が移る （自プロセスがスリープ状態になる）機会は次の場合があります。