Lions' 本読み (70)

kernel

xalloc 手続き、呼び出し元が exec 手続きのみな模様。これ、解説が 14 章で出てきていたんですね。もう少し後でも良いかな、と思ってたりしてます。

気になった部分

exec にも出てくるんですが readi でテキストセグメントとかデータセグメントを読み込んでくる部分の estabur 手続き呼び出し。
以下は xalloc 手続き。

4460    estabur(0, ts, 0, 0);
4461    u.u_count = u.u_arg[1];
4462    u.u_offset[1] = 020;
4463    u.u_base = 0;
4464    readi(ip);

あるいは以下が exec 手続きのデータセグメントを云々する部分。

3138    estabur(0, ds, 0, 0);
3139    u.u_base = 0;
3140    u.u_offset[1] = 020+u.u_arg[1];
3141    u.u_count = u.u_arg[2];
3142    readi(ip);

これ、このエントリで云々してますね。ちなみに下側のデータセグメントを読み出す処理についてはある意味当たり前な記述と言えます。
ただ、何故に 3138 で他の領域はゼロってことで estabur してるのかに関する意図は不明。データセグメントの部分については直前で USIZE+ds+SSIZE で expand してるのがキモと言えるのか。u.u_base にセットされる 0 はデータセグメントの先頭が 0 番地だからね、という理解で良いのかな。
逆にイレギュラーなのは xalloc の方で本来データセグメントであるはずの領域に無理矢理テキストセグメントの部分を読み込んで、すぐにそれをスワップアウトさせてます。
なんとなく手順に沿って列挙してみると

  • swapmap からスワップアウト用の領域を先んじて確保
  • データセグメントな領域をテキストセグメントが読み込めるよう拡張し
  • 読込み (上で引用している部分)
  • 読み込んだ情報をスワップアウト
  • データセグメントもスワップアウト

で swtch 呼び出して戻らない、と。後は sched で再度動き始める時にテキストセグメントが復帰して (ここで始めてテキストセグメントにロードされるのか)、データセグメントの用意ができて、呼び出し元の exec の xalloc 呼び出し部分に戻る、という理解で良いはず。そこからデータセグメントが云々されて、という事なのか。
これを通して sched の 2031 以降を確認すると成程なぁ、と思ってしまいます。

それにしても

この本、順番に読むというより jmp して色々な箇所を確認しつつ、な事が多いなぁ。そういった意味でも再読が必要な本らしい気がしてます。