Lions' 本読み (117) - yamanetoshi's diary

writei 手続き確認着手。
ちょっとぶっちゃけてしまうと、ディレクトリエントリの伸長に関する処理がどこだか分からない状態だったりするのが現状です。
つうか writei 手続きの中身が色々な意味で謎。というのも 6293 から 6319 までの繰り返しの中で直接終了条件に関わる変数にアクセスしてないっぽく見える。

6293    do {

(snip)

6319    } while(u.u_error==0 && u.u_count!=0);

同様にここで問題になっている ip->i_flag についても参照はしてなくて代入のみ。

で

i_flag で xref を全部確認してみたんですが、=& とか =| ではなくて = のみで代入している箇所が二箇所。IUPD と一緒に条件式で使われているのが一箇所。208p から 209p のみ、という有様でした。しかもここから iupdat な記述を確認してみたところ、419p から 420p で記述があるんですが、ここはスルーしてました、というか読んでない (を
IUPD ないし IACC がセットされる手続きが列挙されてて、これをリセットするのは iput のみ (上記 xref 確認した結果もその通りでした) とのこと。
ちなみにテキストのこのあたりに記載されているのは FSV (File System Volume) のリソース管理に関わることな模様。
ざっくり読みます、つってるんですがこれはちょっと方向性がアレ。ちなみに iupdat 手続きは iput 手続きから呼び出されるのか。
これって最後の unlink (ですよね?) で iupdat 手続き呼び出して i_flag をクリアしている模様。

あら?

どこで IUPD を云々しようと思ったかというと

creat (5781) から namei (7518) が呼び出されて
ディレクトリエントリの空きが無くなった場合、ディレクトリエントリの inode なオブジェクトの i_flag 属性に IUPD フラグが立つ

というあたりが契機だったはず。
で、これを呼び出すのが stat1 (6050)、update (7226)、iput (7357) とのこと。

終了

タイムアップ。ええと、iupdat 手続きで 7385 から 7390 で何をしてるのか、を確認、が継続となります。あと、ディレクトリエントリを具体的にどう読みだしているのか、なあたりも確認必要なのかどうか (namei 手続き)。