Linux 拡張ボードデバイスドライバの作り方(用語)

ioperm, iopl
詳しくは man ioperm (2) man iopl(2) を参照.
ioperm(開始アドレス, アドレス個数, 0:off 1:on);
iopl(level); level=0:通常 3:アクセス可
ただし, iopermは0-0x3ffの範囲しか許可できないため, 必要なら iopl を使う. ただし, 全アドレスを使用可能になるため, 危険性を伴う.
out(b,w,l)/in(b,w,l)
MS-DOS などで使う inport outport に相当する関数. 最大の注意点は
outb(値,アドレス);
であり, MS-DOS系やx86 アセンブリ言語と順番が逆である. コンパイル時には -O2 オプションをつけ, 最適化をする必要がある.
プラグアンドプレイの自動設定アドレス
```
例：
cat /proc/pci
                     :
        Non-prefetchable 32 bit memory at 0xec001000.
  Bus  0, device  15, function  0:
    Bridge: Unknown vendor Unknown device (rev 1).
      Vendor id=136c. Device id=9054.
      Medium devsel.  Fast back-to-back capable.  IRQ 10.  
      Non-prefetchable 32 bit memory at 0xec002000.
      I/O at 0x1400.
      I/O at 0x14f0.
  Bus  0, device  14, function  0:
    Multimedia video controller: Intel SAA7116 (rev 0).
                     :
```
この Vendor id=136c. Device id=9054 のボードは aPCI-P54 を増設した際にあらわれるので aPCI-P54 の情報と容易に推測できる. 説明書によると 16バイトの I/Oポートのみを使用するはずであるが, ここではメモリ領域一つとI/Oポート領域２つが確保されている. 実際に読み取り等を行うと 14f0 からの領域がマニュアルにある領域であることが確認できる. 残り二つはなんであるかということになるが, アドテックシステムサイエンス社に問い合わせし確認したところ, ボード上の PCI-LocalBus変換用のICの管理領域とのご解答を頂いている.
カーネル空間
通常のプログラムは互いに保護された排他的なメモリ上で動作している. そのため, 不正なポインタなどを使用したことで, 自分のものではないメモリにアクセスした際に Segmentation fault (SIGSEGV) をおこし, プログラムの実行が停止する. このプログラムから見えているアドレスは仮想的なものであり, 実アドレスではない. それに対して, システムコールを発行すると, カーネル内のドライバなどに実行が移り, 要求した処理がなされる. その際に使用されるアドレスは物理的なアドレスと１対１に対応したものである. つまり, ドライバを書くなどして, カーネルで作業しないとメモリにマップされるI/O(メモリを含むような拡張ボード)は使用できない.
(/dev/mem というデバイスにより, ある程度アクセス可能)

インタフェース製メモリンク IBX-4901用ドライバメモリリードライト部(簡易)

static int ml_raw_read(struct inode * inode, struct file * file, 
                       char * buf, int count)
{
  unsigned long p = file->f_pos;

  if(count>ML_SIZE-p)
    count=ML_SIZE-p;

  p+=ML_BASE;
  r=count;
  outb(MINOR(inode->i_rdev),ML_IO+1);
  memcpy_tofs(buf, (void *) p, count);
  file->f_pos += count;
  return count;
}

static int ml_raw_write(struct inode * inode, struct file * file, 
                        const char * buf,int count)
{
  unsigned long p = file->f_pos;

  if(count>ML_SIZE-p)
    count=ML_SIZE-p;

  outb(MINOR(inode->i_rdev),ML_IO+1);
  p+=ML_BASE;
  memcpy_fromfs((void *) p, buf, count);
  file->f_pos += count;
  return count;
}

static int ml_raw_lseek(struct inode * inode, struct file * file, 
                        off_t offset, int orig)
{
  switch (orig)
    {
    case 0:
      if((offset<0)||(offset>=ML_SIZE))
        return -EINVAL;
      file->f_pos = offset;
      return file->f_pos;
    case 1:
      if((file->f_pos+offset<0)||(file->f_pos+offset>=ML_SIZE))
        return -EINVAL;
      file->f_pos += offset;
      return file->f_pos;
    case 2:
      offset+=ML_SIZE;
      if((offset<0)||(offset>=ML_SIZE))
        return -EINVAL;
      file->f_pos = offset;
      return file->f_pos;
    default:
      return -EINVAL;
    }
  return file->f_pos;
}

memcpy_tofs,fromfs
これは文字通り, 「fsへ, fsから」を意味する. fs はセレクタの一つであり, ドライバ実行時にユーザ空間にアクセスするための手段となっている. 詳細は専門書にゆずるが, セレクタとはi386から導入されたもので, cs,ds など以前セグメントレジスタであったものが拡張されたものである. セグメントは64kbytes固定長であったが, セレクタは可変長であり, メモリ空間の保護(他プロセスによるメモリ領域の侵害防止)などを可能とするものである. fs が i386 以降に追加されたものである.
実際のコードは /usr/src/linux/include/asm/segment.h内の __generic_memcpy_tofs()に書かれている. movs 系列のストリング命令は ds:si->es:diに転送するため, 最初にスタック経由でfsをesにコピーしているのが確認できる (memcpy_fromfs では fs という命令によって ds のかわりに fs を使用).
セレクトの実行機構
file:/usr/src/linux-2.0.35/fs/select.cより推定されるselectの実装機構
1. do_select 内にて, 初期設定後, 一旦タスクは実行状態 TASK_RUNNING から待機状態 TASK_INTERRUPTIBLE に遷移する.
2. selectシステムコールで設定された各条件に対して状況をチェックし, もし, 準備ができていればすぐに TASK_RUNNING にもどし, 処理を継続する.
3. 準備ができていなければ, file:/usr/src/linux-2.0.35/kernel/sched.c内のschedule関数 (タスクスケジューリングの中核)に制御を移し, 別のタスクを実行する. このとき, もとのタスクの状態は TASK_INTERRUPTIBLE であるため, シグナルが入っている場合や時間切れ以外は, 実行されない. シグナルが入ったりすると TASK_RUNNING に遷移させられ, 実行される.
4. 割り込みなどで wake_up_interruptible が呼ばれると, そのタスクは wake_up_process を経て, TASK_RUNNING に遷移させられる. ( file:/usr/src/linux-2.0.35/kernel/sched.c)
5. 一度TASK_RUNNING にうつれば, 次回のスケジューリングからは do_select 内の schedule を呼んだ次の行から実行が再開し, 再度各ファイルの準備状況をチェック, 当然準備ができているはずだから, do_select 終了
wake_up_interruptible で実行状態となったものの, そのあとのdo_selectでデバイスの準備ができていることが確認できなかった場合, おそらく TASK_RUNNING にはなっているため, スケジューリングで schedule から帰ってきては全ファイルをチェックし, 準備ができていないので再度 schedule を呼ぶ, という無駄な処理が続くと考えられる.