Lions' 本読み (49)
ええと、xswap、xfree に xccdec 手続きを確認して swap に突入したら大火傷しそうな深みを確認してしまいました。とりあえず以下に纏めを。
xswap 手続き
なんと言えば良いか分かりませんがそのまんまですね。
- swapmap から領域確保
- xccdec 手続きでテキスト領域を解放するかどうかを確認
- スワップアウトされるプロセスの p_flag を SLOCK な状態に
- swap 手続きで確保した swapmap なナニにスワップアウト
- スワップアウト対象はユーザ構造体以降の領域
- 7 章確認必要
- スワップアウト対象はユーザ構造体以降の領域
- スワップアウトした領域を解放
- 引数で渡されたプロセスオブジェクトの属性を操作
- p_addr にスワップ領域のアドレスを格納
- p_flag から SLOAD および SLOCK を落とす
- p_time を 0 で初期化
あとは runout が非ゼロなら sched な proc#0 を起こしている。
xfree 手続き
この手続きは共有テキストセグメントの破棄とのこと。u.u_procp->p_textp が NULL でない場合、以下の処理をナニ。
- u.u_procp->p_textp に NULL 格納
- xccdec(u.u_procp->p_textp) する
- x_count 属性をデクリメントした結果がゼロで x_iptr 属性の i_mode 属性が ISVTX でない場合
- x_iptr 属性に NULL 代入
- 関連するスワップ領域解放
- x_iptr 属性の i_flag 属性から ITEXT を落とす
- iput は i-node 参照カウントのデクリメントとゼロ値で削除との記述あり
xccdec 手続き
これは一目瞭然ですね。
4495 if((rp=xp)!=NULL && rp->x_ccount!=0) 4496 if(--rp->x_ccount == 0) 4497 mfree(coremap, rp-x_size, rp->x_caddr);
確か x_ccount 属性はコアにロードされていれば、というアレなので参照カウントがゼロになったらコアから解放なのか。テキストセグメントとコードセグメントの取り扱いが明らかに別になってる、というのは面白いですね。
swap 手続き
乗りかかった船、ということでこちらに手を出してしまう。以下が核心部分らしい。
5212 (*bdevsw[swapdev>>8].d_strategy)(&swbuf);
d_strategy て何だよ、と言いつつ unix/conf.h 見てみたら先ず bdevsw を発見。
4617 struct bdevsw { 4618 int (*d_open)(); 4619 int (*d_close)(); 4620 int (*d_strategy)(); 4621 int *d_tab; 4622 } bdevsw[];
v6 の頃からこれ的抽象化な手法は使われておるのですね。K&R 万歳。
そして以下な配列定義を次の頁で発見。
4656 int (*bdevsw[])() 4657 { 4658 &nulldev, &nulldev, &rkstrategy, &rktab, /* rk */
rdstrategy って何だば、と言いつつ確認してみるに RD ディスクドライバな unix/rk.c で手続きが定義されている事を確認。16 章ですね。ここから先に踏み込むと死ぬのは明らかなので一旦停止。15 章も別途確認する方向。race condition なあたりも面白そうですが、とりあえずここまで確認できてれば再度先頭から確認していっても以前とは違った形での理解ができるはず、と信じたい。
最後に
課題を整理しておくことに。
- exec 手続き確認
- readi 手続き確認
- xswap 手続き確認
- newproc でスワップアウトされてしまった子プロセスが起床する瞬間のナニを確認
- malloc/free 確認
上記確認入れつつ再度 6 章 (5 章?) から再読の方向です。