「はじめてのOSコードリーディング」9章 3回目 (2)

9.5 inodeからストレージ領域へのマッピング を読み直しました。

以前ここを読んだ時に、

p.287のitrunc()の12行目の
if((rp->i_mode&(IFCHR&IFBLK) != 0)は
if((rp->i_mode&(IFCHR|IFBLK) != 0)
の間違いのような気がします。

と書いたのですが勘違いでした。

IFCHRは020000
IFBLKは060000
IFDIRは040000

なのでオリジナルの論理だとキャラクタデバイスかブロックデバイスなら何もせずリターンする＝それ以外の普通のファイルまたはディレクトリならデータ領域があるので先に進んで解放する、ことになりますから正しいですね。

ビットではなく値で考えてしまったのが勘違いの原因でした。
しかも12行目ではなく8行目でした(^_^;

誤解に気付くことができたのは多少なりと理解が進んできたからだと思います。

「はじめてのOSコードリーディング」9章 3回目

9章 ファイルシステム を9.4まで読み直しました。3回目か？

ブロックデバイス上のinodeは存在する場所自体がinode番号に相当するが、メモリ上のinodeはその構造体のメンバーとしてinode番号を陽に持つ。

メモリ上のバッファの該当箇所を書き換えてから全体をブロックデバイスに書き出す考え方は随所に出てくるのでかなり慣れてきました。

細部の理解を前回よりも深めながら読み進めたいと思います。

「はじめてのOSコードリーディング」8章

第8章 ブロックデバイスドライバを読みました。

デバイスドライバという言葉は良く聞きますが本当のところどんなものか分かっていませんでしたが、デバイスのopen,close,read,write関数とデバイスの入出力完了割り込みで呼ばれるハンドラがデバイスドライバの実体であるとの記述を読み、イメージが明確になりました。

read,write関数は実際は1つのstrategy関数にまとめられており引数で挙動を切り替える構造にしたのはなぜだろうと思っていましたが、readやwriteを起動するのはHDDのコントローラのレジスタのどのビットを設定するかで変わるので、1つの関数にまとめるのは自然なことだと理解できました。

処理すべきブロックが発生したら処理待ちキューの最後尾に追加する、処理はキューの先頭から行う、先頭の1つのブロックの入出力処理が完了するとキューからはずし次の未処理ブロックがあれば同じことを繰り返す、というやり方は他でも良く見られる構造だと思いました。

残るは最後の 第V部 ファイルシステムです。