tarosukeの日記: ひさかたぶりの俺OS
というわけでひさかたぶりの俺OSなのだが、仮想メモリの設計をちょっと変
更して割合と満足できる設計になったと思うので先へ進んでみたのだ。
# と、言いつつどおしてH8/3067用のコードを??
仮想メモリで変更した部分は「共有メモリに置くもの」をメモリ全体からペー
ジ管理領域だけにしてカーネルから仮想メモリをできるだけ隠蔽した点。これ
でMMUなしの環境とのカーネルの違う部分が隠蔽できる。
カーネル自体で共有するものはそのまま共有するけど、かーねるからみるとほ
ぼ仮想メモリなしと同じになる。違うのはメモリ確保と解放だけなので書き換
えるのはここだけ。なので最初にMMUなしカーネルを書いておいて、仮想メモ
リを後から拡張するような開発の仕方ができるようになったというわけ。
MMUなし環境におけるカーネルは以前開発した事があるのでざくざくと進める
ことだろう。と、いうわけで、今日はIRQの扱いについて設計してみた。
# とはいえ、特定環境専用のカーネル開発に比べると進みが遅いね。
ここには書いてないけど、talosの目標には「高い移植性」というのがある。
特定ハード専用カーネルならもっと迷わずに設計できる、そしてそれを改造す
る時に移植性についてリファクタリングするというアプローチもあるのだが、
MMUの有無についてはそのアプローチでは難しく感じるので最初から設計に盛
り込む事にしたのだ。
PCIなどのバスではIRQは共有される可能性がある以上、IRQは共有される可
能性があるものとして設計しなければならないが、共有されない割り込みのハ
ンドラまで共有されるものとして書くと無駄がでる。俺としては割り込みハン
ドラはなるべく直に呼ばれるようにしたいのだ。
なので、IRQ登録をNetBSDと同様、バスドライバに一任する事にした。つま
り各デバイスドライバは対象デバイスが所属しているバスのドライバにリソー
スの確保を依頼するというわけ。
こうすることでPCIのようにIRQが共有される可能性があるバスにぶら下がっ
てるデバイスのドライバがIRQを要求した時はバスドライバのIRQハンドラリ
ストにそれを追加する。その上で必要とするIRQを上位のバスドライバに要求
するわけだ。で、実際に割り込みが入った時はバスドライバの割り込みハンド
ラがデバイスドライバの割り込みハンドラを呼び出す。という塩梅。
ちなみにIRQを共有しないバスのバスドライバはIRQを要求されたら上位のバ
スドライバにIRQを要求するだけ。処理する必要がないからね。
最終的にCPUローカルバスなどの最上位のバスドライバが最終的にベクタへハ
ンドラを登録して割り込みハンドラの登録が完了する。
と、バスドライバのツリー構造はほとんどNetBSDのパクリなんだけね。実際。
というか移植性の事を考えるとそういう構造になっちゃう。NetBSDのこの辺
の設計はとってもうまいと思う。じゃんじゃん移植されてるのは伊達じゃない。
それにカーネルソースのツリー構造も「複数の設定を同時に扱う」とするとや
っぱりNetBSDに似てしまう。
ひさかたぶりの俺OS More ログイン