説明を書いたが、頭の中で考えるよりも具体的な実装を見る方がわかりやすいので実際のソースを見てみよう。(1)news68kの場合まず一番簡単な例としてnews68kを取り上げてみる。mappedなデバイスであるため、bus_spaceのアクセス系の関数は一種類のみである。あるため、bus_space関数も非常に単純なものになっている。long、つまり32ビット整数になっている。デバイスのベースアドレスそのものが入っている。中身は次のように単純にベースアドレスと指定されたオフセットを足したアドレスを読み出しているだけである。その他のアクセス系関数の中身も同様である。次にもう少し込み入った例としてi386を取り上げる。i386の場合、デバイスが接続されるアドレス空間はI/O空間とメモリ空間と2種類あるため、アクセス時には少なくともこれら2種類を判別して切り替える必要がある。そのバスがI/O空間上にあるのかメモリ空間上にあるのかという情報を持っていることがわかる。デバイスのアタッチメントを呼び出す際に設定される。中身は次のようになっている。(o)))))----------------------------------------------------------------------[注]ここで使われている__BUS_SPACE_ADDRESS_SANITY()はデバッグ用マクロである。I/O系の命令を使い、そうでなければ直接メモリ空間を読み込んでいる。最後に複雑な実装例としてamigaを取り上げる。bus_space関数群を指し示す構造体が含まれている。32ビットアクセス関連の関数は今のところ省略されている。bus_space関数を呼び出す形になっている。attach関数内で対応する関数群が割り当てられる。APIでは、APIの定義自身はあくまでもどの機種にも依存しない形として、その実装のみが機種依存部において個別に定義される形を取っている。APIのアクセス系の関数が呼ばれる場合には間接参照や条件分岐が入ったり関数呼び出しが行われたりという形態になるため、特定の機種専用に書かれたデバイスドライバと比較すると確実にオーバーヘッドは大きくなる。MD部の実装については一通りの実装をするだけではなく性能的な検証も必要になる。デバイスドライバを一から作成する手間やその後のメンテナンスの手間と比べれば、そのようなオーバーヘッドは取るに足らないものであると言えるだろう。具体的には、デバイスが接続されているバス空間のどこにそのデバイスが配置されているかというアドレス情報のこと。実際にはnews68kの拡張ボードのいくつかはR3000系のnewsmipsでも共通に使えるものが存在するため、理想的にはそれらのドライバはMI部に存在するべきである。mappedアクセスされるだけで特に複雑な設定を要しないとかそもそも対象となるデバイスがほとんど存在しないとかいった理由で今のところMIにはなっていない。マイナーなデバイスでどこまでMIとMDの分離にこだわるかというのは実際のところ実用性と一貫性とどちらをとるのかというほとんどポートメンテナーの趣味の領域の話になる。使用するようにも切り替え可能であるが)。持っていないものがあったりデバイスのアクセス方法が特異なものがあったりでこれも今のところ作業は進んでいないようである。実をいうと拡張スロット上のデバイスのサポートはかなり手抜きをしている上まだ実装していない部分もあり全然動作確認をしていない。そのあたりに謎なコードがあっても深く追求しないでいただきたい。これは単に筆者がソースコード中の記述から判断しただけの話であり、筆者は別にamigaに詳しいわけではないので、ハードウェアが実際にそうなっているのかは未確認である。複数回のアクセスをループで行うmulti系やregion系の関数などでは極力条件分岐を減らすなどの最適化が必要である。;-pNetBSDのページに戻るtsutsui@ceres.dti.ne.jp。