[minix] minixのソースを読んでみる その１

toolはvim + gtags + gdbでつきすすむ。　csopeは却下！　というか使い方がよくわからない

gtags -v + htags を実行してhtagsで作っておいたHTMLもwebで見られるようにしておいた

作ったソースはここにあります.

以下は読みながらとったメモ　あとでまとめる予定

minix source

kernel.h 役割　includeする

PUBLICって何？　定義を教えてもらいたい

PUBLIC void kprintf(const char *fmt, ...)

kprintfの定義. kの使用方法はよく分からん.. 考えてみる

[使用方法]

kprintf();

てな感じかなぁ。.

va_start(argp, fmt);

すべての始まり

va_end(argp)

すべての終わり

PUBLIC void panic(mess, nr)

panicking++ recursiveって何さ？

PRIVATE void shutdown(tp)

shutdown関数

how = shutdownの仕方

realmode or protected mode

minixはkillじゃなくてsend_sig関数になってる

使用例

send_sig(proc_nr(rp), SIGKSTOP);

(int proc_nr; int sig_nr)

rp = proc_addr(proc_nr);
sigaddset(&priv(rp)->s_sig_pending, sig_nr);
lock_notify(SYSTEM, proc_nr);
}

proc_addr(n) (pproc_addr + NR_TASKS)[(n)]

lock_notify(SYSTEM, proc_nr);

(src dst) 引数

result = mini_notify(proc_addr(src), dst);

(sender of the notification, which process to notify);

shutdownはprepare_shutdownからのみ呼び出される。

cause_sig発見　おもしろいことしてるじゃないか

image[]

table.c has most kernel data

lovckの定義が謎

#define lock() (++dep->dep_int_pending_sys_irqdisable(&dep->de_hook));

lockの定義が多すぎる。　undefしたりdefineしたり..

rm_lru()

chainを刑した処理を実行している

cache.cで呼ばれている
get_block関数でな

block構造体を見るのが先決

struct bufはbuf.hで定義されている

buf {

union {..}

struct buf *next;
struct buf *back;
struct buf *hash....

}

zone_t 型とは何ぞや？

ソースコードを読むとはジグソーパズルをするのに似てる。全体を理解するために一つ一つの
ピースを観察したり、くっつけあいながら全体を完成し上げるのである。

do_read()

return(read_write(READING));
}

なんとread_write()の引数はint型のREADINGもしくはWRITINGのみだとさ

なんてこったい

READINGってどこでていぎされてるのよｗ　ジグソーパズルとの違いはコードには視覚的な情報が無いという部分
が最も大きいと思う。自ら工夫しソースに色づけなどをししっかりと意味を理解しなければいけない。

この工夫のさじ加減が理解力の差とつながっていくのである。ジグソーパズルといっても昔あったような牛乳ジグソーパズルのように全部白でピースの形だけを
頼りに組み立てるのあがあれば、ミッキーマウスのジグソーパズルのように視覚的にはっきりとした特徴のあるのもある。

千差万別なのである。

do_read→read_write()→read_write内で複雑な処理をすることになる　read_writeを読み解くのがかぎとなるであろう

わざわざread_writeでreadとwriteの処理を分岐しているのは、これら２つが同じような構造をしているからなのだろうか？
少し謎である。

read_map() mapとはなにをさすのか？

コードの処理内容を比喩で表すのもよいかもしれない

dup_inode(ip) {

ip->i_count++してるだけだし,,
}

呼び出しについて考える。どっか人ｔの箇所から呼び打差荒れていると考えられるが其れはドンなもんかなぁと

dup_inodeよばれまくりんぐｗ

目的を持って読まなくてはならない。目的なくして読むのは地図なくして航海に出るようなものなので
あなたがコロンブスだとすると新大陸を見つけることはできないだろう。きっと遭難してしまう.
そう、ソースコードを読む際にやみくもによんでもソースコードという海の中であなたはきっと遭難してしまうでしょう。
しかしながら、ソースを読むためのツール、これはいわば航海にのぞむコンパスやそのたの航海道具などの役割
をもつものと考えられます。

やる際にはきちんと精読しましょう。あっちいったりこっちいったりしてもむろん大陸なぞ見つからないでしょう

rename system callについて知りたいひとはこれを読むといいさ。
do_rename()
{

link.c
はじめにやること　このコメントのとおり

/* See if 'name1' (existing file) exists. Get dir and file inodes. */
if (fetch_name(m_in.name1, m_in.name1_length, M1) != OK) return(err_code) ;

name1があるかどうかinodeをさがせとな..

inodeにどのようにname1が格納されてるかしらなければこれをよみとくことはできませんね

とりあえずfetch_name()関数について調べましょうかね

fetch_nameでname2があるかどうか調べる

advance()でなんかする

以下略

inodeの処理をするので結構複雑。　よみたきゃよめってかんじ
put_inode()とか読んどくことをおすすめする

remove_dir()

dirをけす。inodeの処理が中心となる。　inodeについて詳しくなりたい人はよむといいさ
それほど難しい処理ではないはず

始めに処理すべき内容について言及されている

unlink_file() {

}

unlinkするのさ。するのさ。するのね　するのね

advance() ゲームボーイとは関係の無い関数らしい

コメントから読み取るに、inodeからdir nameを検索する関数らしい。　advance()って感じじゃないね

引数が条件満たすかどうか検索する

色々なしょりして、最後にポインタ返すんだね

main処理はsearch_dir関数で行われている

put_block()関数とか大体の処理内容はわかるが微妙に分かりそうでないようなガクブルな内容なので困る

NIL_INODE そんなINODE NILだZEって感じかな

まとめ　advance()関数は名前と処理内容が微妙に違う気がする。たねんばねうむ先生のセンスがあらわれてるといってもよいとおもう」

rip = return ipであるのさ

inode.cそのものはたったの366行である