最近Googleアカウントを色々いじっていたので、Bloggerを思い出した。
どうやら仕様が変わっている模様。
http://ntakano75.blogspot.com/2008/04/blog-post_8146.html
これを参考にトラックバックの設定をもう一度やり直す。
そんでテスト。
http://d.hatena.ne.jp/n314/20080531/1212230717
ここにトラックバックを打つ。
2008-05-31
久しぶりにここを見た
2006-07-20
ファイル読み書きのタスク
| ストーリー | pt | タスク |
|---|---|---|
| ルートディレクトリのread | 6 | i-nodeのread ファイルのopen ファイルのread |
| ルート直下のファイルのread | 2 | 確認のみ？ |
| ファイルのwrite | 4 | i-nodeのwrite ファイルのwrite |
| ディレクトリのwrite | 2 | 確認のみ？ |
タスクが想像つかないっていうのも微妙。
本当にこれだけで実装できるか、というか想像していることが可能なのかが分からないけれど、取り敢えずやってみる。
前回は10ポイントで二日だったので今回は三日、だといいんだけれど。。ファイルの基本操作のやり方が一通り分かればイテレーションっぽくやりたい。
2006-07-15
/procにファイルを作成
ディレクトリとファイルを作成できた。
所要時間は2日くらい・・・実質プログラムしていた時間は数分だが、色々他のことも調べていたら時間がかかってしまった。
XPではこういうことはあり得ないんだろうな・・ペアでやる時間がきっちり決まってるし。
実際にprocに関して調べていたのは2時間くらいかな。
で、所要時間を2日とするか2時間とするか。
タスクに関連しない調べ物は他の時間にやることにして・・。
2時間としておこうか。
詳細
http://kernel.g.hatena.ne.jp/katase_n/20060715/1152953244
それでタスクを分けたわけだが、初めだから適当にって思って適当にしすぎたみたいだ。
順序としては
- ファイルを作成
- ファイルに情報を表示
- ディレクトリを作成
- ディレクトリの中にファイルを作成
- ディレクトリの中のファイルに情報を表示
まぁ5は2と同じなのではぶくとして、ファイルが作成されていることをチェックしたらその中の情報もついでに取得するのが普通だ。
そしてどちらも粒度が細かすぎた。ストーリーが一つしかないのに無理矢理二つに分けたからか。
内部の情報を管理する機構とprocfsを扱う機構は別である。
が、内部が動いているかをテストするにはprocfsがまず必要だった。要するに今のところ情報を取得するのはprocfsを利用するしか方法が無いので、procfsに関する機能は全てのテストに関連するということだ。
内部の構造とprocを合わせたら、トータル二日で調度良いのかも。
次はもう少し考えてからやってみよう。
イテレーションに区切るのはコツが掴めてからで。
ループバックマウントの動作
ファイルシステムの調査に関するメモを
http://kernel.g.hatena.ne.jp/katase_n/20060714/p1
こっちに作成。
ここは開発に関するメモということで分けてみた。
2006-07-14
自動テスト
環境の設定ってストーリーに含まれないのかな。
顧客から見たら関係ないしなぁ。
自動テストというか自動ビルド環境を作ってみた。
スクリプトを実行すると次の処理を行う。
- ファイルシステムのコードをvmwareにコピー
- リモートログインでファイルシステムをmake
- テストケースのコードをvmwareにコピー
- リモートログインでテストケースを実行
そんでテストケースはスクリプトで
- モジュールインストール、ディレクトリを作成してマウント
- /procのファイルを読み込む
システムコールの関数は後でC言語で書くことにする。
mountシステムコール
システムコールからのマウントの流れ
sys_mount()
ユーザ空間から受け取ったパス名などをカーネル空間のバッファに移す
do_mount()
マウントするパス名をnameidataに入れてマウント処理を行う
do_new_mount()
do_kern_mount()を呼び出してマウントし、vfsmount構造体をdo_add_mount()に渡してnamespaceツリーに追加する
do_kern_mount()
get_sb()でスーパーブロックを取得し、その値からmnt構造体を初期化する
スーパーブロックとかi-nodeからパス名を取得するにはどうすればいいんだろう。。
地道にディレクトリ名を繋ぎ合わせていかなきゃだめなのかな。
2006-07-13
テストファースト
ユニットテストはpublicな関数だけテストするからカーネルから呼び出される部分のみテストすればいいのか。
で、テストに情報取得が必要なら情報を取得するインターフェースを作成する。
例えばメモリがちゃんと割り当てられているかを調べたいなら、メモリの割り当て状況をチェックする関数を作成する。
将来的にはユーザがファイルシステムの状態をチェックできるようにしなければならないのなら、それを先に作っても同じだ。というより、先に作らなければならないということがテストファーストによって浮き彫りになったということなのかな。
取り敢えずテストを書いてcreate_proc_read_entry()を使って情報を取得できるようにしてみようか。
VMwareにDebianをインストール
しょっちゅうカーネルパニックを起こすわけにもいかないのでDebianのVMware上にDebianを入れる。
VMwareはvmware-serverを使用。
前にWindows上のvmware-playerでkdbを使ったらWindowsまでバグってしまったのでkdbを使うときだけはそれ専用のPCを使うことにする。
apt-get install kernel-headers
で、さっきのURLのソースをほとんどそのまま書いてinsmodしたら動いた。
inodecacheとか変なところで迷ってたけど、それを利用しなかったら短いソースで出来るんだな・・。
マウントは /dev/fd0 を適当なディレクトリに。
実際のフロッピーを使わずにfloppy.imgをVMwareに設定しているのでHDDと同じように扱える。
テストファーストを行う場合、テストケースを書くツールが必要になる。
ファイルシステムの関数はユーザが呼び出すのではなくてカーネルが呼び出す。
ということはカーネルから呼び出すのと同じような処理を行うフレームワークが必要なのか・・。
テストファーストは諦めるか。。早くもアジャイル開発失敗の予感。
ファイルの操作、open()だのread()だのはテストできるけど、作成するファイルシステムのstatic関数をテストすることは出来るんだろうか。。
これが出来ないとユニットテストにならないよなぁ。。
そしてユーザモードでテストしても意味がない。
というかカーネルの中で使われている関数をテストできない。
しかしカーネルモードでテストって・・・結局カーネルに組み込まなきゃいけないんじゃ・・。うーん。
LTPのダウンロード
http://ltp.sourceforge.net/ltphowto.php
ここを参考にする。
まずはltp-fullのアーカイブをDLして展開する。
Debianのtestingにltpパッケージが含まれているが、aptで入れようとするとlibc6などがアップグレードされて何やら危ない予感がするのでやめておいた。
テストは
runtest/command_file
にコマンドを記述する。
ここでのコマンドは
testcases/bin/
以下に格納されている。これは testcases/* 以下に階層化されているテストケースのハードリンクを集めたものになっている。
- サンプルドライバpan
ドライバコード
pan/*
テストスクリプト
testscripts/runpan.sh
コード ${LTPROOT}/pan/pan -e $@ -a ltp -n ltp -f ${LTPROOT}/runtest/quickhit
quickhit
access01 access01
...
テストケース実行ファイル
testcases/bin/accesses01
テストケースコード
testcases/kernel/syscalls/access/*
例えばファイルシステムのi-nodeのテストケースは
testcaces/kernel/fs/inode/*
あと
testcases/kernel/device-drivers/*
とか。
って見てると、どうもregister_filesystem()が無いっぽい。
VFSに関するテストとかは含まれてないのかな・・・一通り動くものが出来てからのシステムコールのテストしかないような。
検索してたら
http://lwn.net/Articles/57156/
こういうのがあったので、これを参考に一通り動くものを作ってみますか。。
登録:
投稿 (Atom)