from-****@i-lov*****
from-****@i-lov*****
2007年 7月 25日 (水) 15:24:14 JST
熊猫です。 > 1.開発環境について(コンパイル環境、試験環境の構築方法) > きっと、linuxをインストールして開発資産一式をおいて・・・と想像しているんですが、 > 開発資産のコンパイル確認や解放(TOMOYO プロジェクトではリリースというのでしょうか?)作業などを視野に入れ > 特別な環境構築等はおこなっていらっしゃいますか？ > もしくはこういうスタイルが良いという様なことがありましたらお願いします。 各ディストリ用の VMware イメージを作成し、 VMware 環境からカーネルパッチ（ ccs-patch-\*.txt ）の作成と バイナリパッケージの作成を行っています。 処理部分（ ccs-patch-\*.txt 以外のファイル）の開発は １つのディストリ（ CentOS 5 ）でのみ行っています。 ユーザランドツールも１つのディストリでのみ開発を行い、 各 VMware 環境にコピーしてコンパイルが通るかどうかを確認するだけです。 （ユーザランドツールにはカーネルのバージョンやコンフィグに依存するような処理は含まれていません。） コンパイルしたものを逐次 scp でコピーし、アップロードしています。 ということで、「開発資産一式」というほど大げさな表現を使うような「特別な環境構築等」はありません。 > 2.過去の開発での試験実施方法 > 環境にもかかわると思いますが、カーネルの試験をするとなると、 > 通常のアプリの試験とは少し違うのではと想像しています。 はい、違うと思います。私は通常のアプリの開発に携わったことが無いのですが、 通常のアプリの場合は「操作１をしてから操作２を行い、その結果に応じて 操作３または操作４を行う」といった風にたくさんの操作を組み合わせた試験を行うと思います。 カーネルの場合は、「ファイルを作成する」「ファイルをオープンする」 「ファイルを削除する」のように、単純な処理しか扱わないため、 複数の操作を組み合わせた試験にはなりません。 （ＯＳ層では資源へのアクセス要求を処理し、アプリケーション層では アクセス要求の発生順序を制御するという違いがあるためです。） > あと試験ツールなどがありましたらあわせてお願いします。 現状、 ccs-patch-\*.txt の漏れが無いかどうかを確認するためのテストを行うものしかありません。 ccs-tools-\*.tar.gz （ソース版パッケージ）を展開することで得られる ccstools/kernel_test/ ディレクトリに試験ツールが含まれています。 make -s all でコンパイルして、 ./testall.sh を実行するだけです。 試験ツールの実行は数秒で終わります。 普通のアプリ開発とは異なり、例えば 1.4.0 と 1.4.1 の２つのバージョンをメンテナンスすると 維持コストが２倍になるかというとそうではなく、せいぜい動作確認の所要時間が数分長くなるだけです。 その代わり、試験ツールの試験項目に漏れが無いかどうかの確認は非常に難しいところです。 カーネルのバージョンアップに伴いどんどん機能が増えていきますが、 どんな機能が増えたのかを追いかけながら試験項目を作成していく必要があります。 試験ツールのテスト項目の作成効率は最低です。 試験ツールのテスト項目の作成を手伝っていただけるようになると非常に助かりますが、 そのためには最新カーネルに関する知識およびシステムコールに関する知識が必要になります。 熊猫も全ての項目を網羅できているかどうか自信ありません。 ユーザランドツールの動作確認は、ほとんど editpolicy.c が対象です。 initialize_domain や keep_domain 等の指定を追加したり削除したりしながら Domain Transition Editor での画面表示が予想通りの動きをしているかどうかを検査します。 ユーザランドツールの動作確認には最新カーネルに関する知識は不要です。 TOMOYO Linux の仕様を理解してテストケースを作成することができれば誰でも行うことができます。 > 単体試験、結合試験、連動試験(F用語ではPT IT ST OTなんていうのですが) > と言うような工程もやはりあるんでしょうか？ アクセス要求の発生順序を組み合わせることをしないため、 単体試験、結合試験、連動試験のような区別もありません。 > 3.開発資産 > 過去に開発してきた箇所にフォーカスして見たいと思いますので > 開発箇所を教えてもらえるとありがたいとです。 えっと質問の意味がよく解らなかったのですが、 ・書き込みモードでのオープン（2）以外の書き込みアクセス（create link unlink等）を 書き込みモードでのオープンと区別するようにする ・強制モードにおいて、ポリシー違反が発生した場合にすぐにアクセス要求を拒否するのではなく 対話的にアクセス要求の諾否を指定できるようにする ・ aggregator により複数のプログラム名を単一のプログラム名にマッピングできるようにする ・ドメインを削除せずに、ドメインに対するアクセス許可を削除できるようにする ・シンボリックリンクの名前のままドメイン遷移をできるようにする ・ \*.txt のような指定ができるようにワイルドカードのパターンマッチング規則を改める ・ IP アドレスとポート番号に基づくアクセス制御ができるようにする ・ if 節を用いてユーザ ID 等に基づくアクセス制御ができるようにする ・ドメイン単位で制御モードを指定できるようにする ・ファイルの書き換え（追記ではない書き込みモードでのオープン）を禁止できるようにする ・ポリシーの読み込みを /.init に行わせることでポリシー管理方法の自由度を高くする ・ keep_domain および no_keep_domain によりドメイン遷移の要否を指定できるようにする ・ initialize_domain および no_initialize_domain によりドメイン遷移初期化の要否を指定できるようにする ・ポリシーの変更を許可するプロセスをドメイン名でも指定できるようにする ・ path_group によりパス名をグループ化できるようにする ・ address_group により IP アドレスをグループ化できるようにする ・ argv[0] の改ざんによる（ busybox の）想定外の振る舞いを禁止できるようにする ・ \- により特定のパス名を除外できるようにする といったところでしょうか？（ README.ccs から主なものを抜粋しました。） > まだまだわからないことが多くなかなかお役に立てないのですが、 > 早く戦力になりたいと思っていますのでよろしくお願いします。 > 開発会議で皆さんにお会いできることを楽しみにしております。 こちらこそよろしくお願いします。
TOMOYO
Fork