From: hasegawa@fip.co.jp
Subject: [b-free 64] B-Free News letter vol 32
Date: Wed, 14 Aug 1996 09:55:56 +0900
Message-ID: <199608140052.JAA13635@center01.fip.co.jp>
> その2
> 現在、カーネルは少しずつAT互換機に移植が進んでいます。しかし、
> 周辺核が進捗がほとんどありません。そこで、もっとうまく開発が進むような
> 方法を検討中です。
> みなさんもいいアイデアがあればお願いします。
私自身の反省も込めて、周辺核の開発がなぜ遅れてしまったのかを考えてみま
す。
とりあえず、個人のスキルの問題という観点は置いておきます。プロジェクト
全体としてどうして遅れてしまったかというところから問題点を考えてみます。
1) プログラムを分断して開発してしまった
まず、周辺核の開発を複数の人に分けたことが遅れの原因ではないかと思います。
周辺核には、たとえば、プロセスマネージャはファイルマネージャの機能を使
うというように、他の周辺核の機能を使用します。そのため、周辺核の開発に
は周辺核同士の通信(つまりメッセージですね)の形式を決める必要があります。
そのためには、周辺核を開発する人同士の密接な相談が必要なわけですが、月
一のミーティングではあまりにも密度が低すぎました。
周辺核の担当者同士の通信環境にもばらつきがあり、担当者同士の連絡も必ず
しも円滑にいきませんでした。
2) 開発環境の構築に労力が必要だった
開発者にとって、開発環境を構築することが第一の壁になってしまいました。
B-Free OS は、Linux 上で作成しています。
これは、私自身の一番やりやすい開発環境をとったためです。しかし、私の他
のメンバーでは、Linux をインストールしている人が意外に少なく、B-Free
OS を開発するために、Linux のインストールと make 環境の構築という余分
な労力が必要になります。
3) 開発の目標が曖昧だった
周辺核の開発では、途中の目標というものがなく、「とりあえず動かす」という
曖昧な目標だけがありました。開発に優先順位というものがなく、場当たり的
に開発をしようとしていました。そのため、開発がどこまで進んだからを知る
手段がなく、結果として開発がどんどん遅れていってしまいました。
また、中心核の場合、まず最低限のものを動かし、それを基に開発をしていき
ました('94 年終盤から '95 年のはじめの頃)。機能は少なくとも動くものが
あれば、新しい機能を追加しテストすることができますし、何よりも開発の励
みになります。
しかし、周辺核を動かすには他の周辺核の機能が必要なため最低限の機能を動
かすことがむずかしく、動かしながら開発という手段が取れませんでした。
--- B-Free プロジェクト実行中! 詳細はこの WWW へ -> (http://www.b-free.orient.co.jp/)内藤隆一 (ggc00661@niftyserve.or.jp/night@bfree.rim.or.jp)