小久保和宏
dai-y****@gaea*****
2007年 8月 1日 (水) 13:45:42 JST
こんにちは。小久保です。 私も参加したいと思います。 どの程度お役に立てるかは未知数ですが・・・。 > たけだです。 > > 協力の意思表示、ありがとうございます。m(_ _)m > > 作業をしていただくときにまた説明しますが、 > 最近のカーネルに付属しているscripts/checkpatch.plにパッチを食わせれば、 > スタイルのチェックを行ってくれます。 > これの出力をベースにクリーンアップ作業を行っていただければと思います。 > > たとえばこんな感じの出力が得られます。 > ----- > [root ＠ etch]# checkpatch.pl patches/tomoyo-mount.diff > WARNING: externs should be avoided in .c files > #24: FILE: security/tomoyo/mount.c:15: > +extern const char *ccs_log_level; > > ERROR: do not initialise statics to 0 or NULL > #54: FILE: security/tomoyo/mount.c:45: > +static struct mount_entry *mount_list = NULL; > ----- > ある程度機会的にスタイルを修正できます。 > > 実際にTOMOYOのコードのスタイルをチェックして修正してみるとわかるのですが、 >> - 行の長さは80カラム以内 > を達成するのが一番難しいです。インデントが深いのが主な原因ですので、 > ロジックの変更、関数の切り出しなどが必要になります。 > > また、関数の切り出しという意味では、 >> - 関数の長さは80x24で2画面以内がのぞましい >> - case文があって長くなるのはかまわない >> - ローカル変数は５から１０個程度がのぞましい > これらは現在のcheckpatch.plでは検出されませんし、 > たけだがすでにやったファイルでもこれらは修正しきれていません orz > #この辺がけっこうタイヘンです。 > > また、たけだがやってきたクリーンアップ後のテストは地道です。 > ・ccstools/kernel_test以下のツールで学習とアクセス制御が動くことを確認 > ・修正箇所が影響を与えうるロジックを走してみる > ・/proc/slabinfoを見て単調増加してないかチェック > > クリーンアップやテスト方法でいいアイディアをお持ちの方が > いればぜひお知らせください。m(_ _)m > #過去にはソース資産が膨れ上がって身動きの取れなくなった開発の #建て直し専門チームのリーダをしてたので、クリーン化、作り直しなど #個人的にはこういうのは得意だったりします。 #まだ対象となるソースを見ていないのでなんともいえないですが、 #たけださんの行ってきた機能レベル確認と言った視点と #機械的な方法としては純粋に影響関数下のインタフェースを切り出しての #関数レベルでのインタフェースイベントの網羅確認など手法があると思います。 #作業着手段階になったら(すでにその段階?)スケジュール、方法、分担を皆さんと議論したいと思ってます。 #その前に、私自身の作業をするマシン環境を確保しないと。もう１台PC買うか・・・
TOMOYO
Fork