6.828: Operating System Engineering (38)

kernel

基本的に virtual address は page directory とか page table とかを介してページフレームの番号 (pages のインデクス) に変換できる、はず。
ちなみにうにまがのあの記事によれば、Linux ではプロセス毎に独立したアドレス変換テーブルがあるとの記述がある。xv6 はどうなのだろうか。

というか

pgdir_walk 手続きの仕様ですが、

  • va から page table entry な pointer を取得して戻す
    • (pte_t *)KADDR(PTE_ADDR(pgdir[PDX(va)])) がそれに当たります?
    • うう、なんか違うぞ
  • あと、page tabale doesn't exist なソレがイメージできてない
    • ええと、pte_t なナニから pages なインデクスを求めるマクロとかあるのかどうか
    • pa2page な inline 手続き?
      • page_lookup で戻った pte_t なソレから求めるのか

うーん、page_lookup と pgdir_walk で何をしなければいけないのかがイメージできてない。
page_lookup は

  • pgdir_walk から戻った pte_t なポインタを使って struct Page なアドレスを戻せば良いみたいに見える
  • 戻ってきた pte_t * なソレを引数の pte_store に格納するのか

やっぱ pgdir_walk が NULL を戻すのがどんなケイスかがイメージできてないのか。ページテーブルが物理アドレス空間にマップされてないケイス、と言えば簡単なのですが、ここで複雑なケイス (複数プロセスが同じスペースを使って云々とか) を発想してしまって、ドツボに入ってしまう。
あ、phys address を取得できたら pages なポインタを取得できる、とあるので、page_free_list から始まるリストにあるかどうか、は分かるな。成程、それで walk なのかな。
答えが見えたのかどうかは不明ですが、とりあえず今日は休みます。

と言いつつ

page_alloc か。これ、page_free_list から最初のエントリを持ってきて戻してる実装になっているのですが、上の考え方はダウトかも。
とりあえず現時点での page_alloc の実装はダウトだな。
や、呼び出し元に担保を求めているようなコメント記述もありますね。当たりかハズレかな判断が微妙。
ああ、分かった。page_alloc で先頭から取り出してそれを使ってね、なソレが微妙なのか。よく考えたら

int
page_alloc(struct Page **pp_store)

なプロトタイプなんだからここでもパースして該当位置を戻せよ、って話なのかどうなのか。