「9.5 inodeからストレージ領域へのマッピング」をもう1度読んでみました。
完全ではないですが、前回よりも細部まで理解できてきました。少しほっとしています。
本節では関数の引数にinode[]エントリを持つものがいくつか出てきますが、その引数の型を struct inode *ip; としている関数と int *ip; としている関数があります。
関数の中身を見ると引数の型に関わらず同じように使われているようですので、当時のC言語ではどっちでもいいので何となくこうしただけみたいです。フラグの特定ビットが立っているかどうかの判定も特定ビットだけを立てた定数とandをとったものをif文の条件部に直接書いたり0と比較したりと統一されていません。
と言うことで表記の統一に関してはそれほど厳密には行われていないようですね。ちょっぴり人間味を感じました。
p.283にbmap()に直接参照だったファイルが書き込み処理によってファイルサイズが大きくなり間接参照に変える処理がありますが、逆にファイルの中身を編集して減らして行って間接参照だったのが直接参照できるようになった時の処理はありません。
と言うことは1度間接参照になったファイルはその後サイズが縮んでもずっと間接参照になるのかな?
p.287のitrunc()の12行目の
if((rp->i_mode&(IFCHR&IFBLK) != 0)
は
if((rp->i_mode&(IFCHR|IFBLK) != 0)
の間違いのような気がします。
完全ではないですが、前回よりも細部まで理解できてきました。少しほっとしています。
本節では関数の引数にinode[]エントリを持つものがいくつか出てきますが、その引数の型を struct inode *ip; としている関数と int *ip; としている関数があります。
関数の中身を見ると引数の型に関わらず同じように使われているようですので、当時のC言語ではどっちでもいいので何となくこうしただけみたいです。フラグの特定ビットが立っているかどうかの判定も特定ビットだけを立てた定数とandをとったものをif文の条件部に直接書いたり0と比較したりと統一されていません。
と言うことで表記の統一に関してはそれほど厳密には行われていないようですね。ちょっぴり人間味を感じました。
p.283にbmap()に直接参照だったファイルが書き込み処理によってファイルサイズが大きくなり間接参照に変える処理がありますが、逆にファイルの中身を編集して減らして行って間接参照だったのが直接参照できるようになった時の処理はありません。
と言うことは1度間接参照になったファイルはその後サイズが縮んでもずっと間接参照になるのかな?
p.287のitrunc()の12行目の
if((rp->i_mode&(IFCHR&IFBLK) != 0)
は
if((rp->i_mode&(IFCHR|IFBLK) != 0)
の間違いのような気がします。