[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1205] Re: オブジェクト指向の OSへの適用(Re: スケジュールについて)



ちょっと、この発言だけ、先に、res つけときましょうか。



Ryuichi Naitoh wrote:

> 隆一です。
>
> # 長いです。

了解。覚悟しました。^_^;

> > まあ、大抵は、お互いの誤解なんですが、、、。
>
> 誤解、というか、スケジュールの話をするときに、オブジェクト指向 OS にし
> ようというのは、読み筋が違っているのではないかと。
>
> 確かにこーゆー話はしていて楽しいです。けど、実装に入った段階でする話で
> はないのでは? それをするなら、「今の B-Free OS はダメダメだから、一か
> ら作り変えよう」ということを言わないと。

その通りですね。ただ、問題は、四年前はOSをOOになんて事はなかったんじゃないかなぁ。
それが、最近になって、状況が変化してきている。

だから、B-free では、
 「よっしゃ、もういっちょ最初っから、考え直すで!」
か、
 「まあ、OOPも良いけど、とりあえず next version まではこのまま行こう」
か、どちらかを選択しなきゃいけないわけです。

後者を選択するなら、とりあえず、完成はぐっと近くなるでしょうね。
# 逆に前者を選択したら、大変でしょうねぇ。
OO云々の話は「すぎたこと」として、OOを期待している人達に対しては「また今度ね。」という話
になるだけです。

その辺の方針をはっきりしておくことが大切なんだと思います。


> > まず第一に、OOP にするかどうかで、Manager の割方とか、全部、違ってきます。何故かという
> > と、それが、OOPだからとしか、、、、。(笑)
>
> それそれ、そこをちゃんと説明しないと。
> まず、前提としてオブジェクト指向が優れているということがあって、そ
> こが議論の出発点になっていませんか?

そう言う出発点には(ぜーんぜん)立っていません。優れていると言うより、実装のための outline
を定めたいという話です。
以下参照。

> Manager の割方が違ってくるということは、OS の全体の構成を変えるという
> ことですよね? その構成を変えるためにはどのくらいの労力が必要になるで
> しょう?

うーん。今のところ、ITRON 核しか出来ていないわけですし、、、、。
これが、Manager が大分出来ていて(実装されていて)、で、これから変えようと云うなら話は別です
が、、、。

# ITRON核はそのまま使えると思います。
# どちらにしろ。

> もちろん、オブジェクト指向言語には色々利点があると思います。ただ、その
> 利点は OS の作成においては、あまり目立ってこないと思います。ましてや、
> スケジュール問題の解決にはとても役に立ちそうにありません。

schedule について言うなら、一つ僕が言い続けているのは、「形が見えてこない」というのがありま
す。色々な人が色々な理想を言うと、その最小公倍数で作ろうと言うことになり、そうすると、すごく
曖昧な感じになっちゃうんです。
実装なんて、すべての要求を満たすのは非常に難しいことは了解ですよねぇ。
絶対切り落とすところがでてくる。
で、あれもこれもと言うと、じゃあ”実際”の実装はどうしたら良いのと言う話になる。

僕がOOのよい点と思うのは、outline からどんどん細部に詰めていけると言うところです。
Design が top-down なんですよ。
OOというのは、module より一つ level の高い抽象化なんです。
全体を大きな固まりでとらえて、その間の関係を調べて、実装で達成しなければいけない goal を見つ
けだしていく。
その点、module から、buttom-up で作っていこうとすると、僕には今一つピンとこない。
一つの program を module で作るのは良いんですよ。だだOSの場合、いくつもの module が相互に
干渉し合うじゃぁないですか。そこで、その干渉の結果として、もう一つ高い次元の抽象化があると、
話がまとまりやすいのです。
良く思うのは、例えば、Memory Manager が提供する機能が「それで十分なのか、多すぎないのか、性
能を何処で出すか、仕様上の欠陥はないか」とか、今一つ、全体の仕様の必然性に欠けるように見えて
しまうのです。その API が「何故」必要なのか、全体として「どう」機能するためにあるのか、とい
う理由付けが欲しいんです。


> 私の書いたのは OS をオブジェクト指向言語でオブジェクト指向の機能を使っ
> て記述する話とアプリケーションレベルのクラスライブラリの話です。

僕が「OSの上に、OOPな言語を被せる。」と言ったのも、そう言う意味でした。
で、もう一つのOOは、OS自体をOOにするんですよ。

例えば、API の overload とか、そう言ったことから始まっていく話です。

はっきり言えば、Cで書いても、Pascal(暴言1) で書いても、OSはOOになるんです。
同時に、OSの上の開発環境をOOPにしたところで、OSは依然としてOOにしないことが出来るん
です。

Win95 とか、Borland はOOPな開発環境を提供していますよねぇ。C++ で。
でも、Win95 は、OOなOSではないと思います。

その点、BTRON2は、まさに、OOなOSだと思います。


> OS をオブジェクト指向化するというのはいろいろ視点があると思います。そ
> の中にはオブジェクト指向の機能を使って、オブジェクト指向言語で書くとい
> うのも含まれるでしょう。

というわけで、開発環境をOOPにするわけではないと言う視点で、もう一度発言を読み直してもらえ
ると助かります。

# 開発環境はOOPだろうが何だろうが
# どうとでもなる。


> 今の B-Free OS のデザインは、非常に粗いレベルのオブジェクト指向とも言
> えますよね。
> オブジェクトとして各マネージャがあって、オブジェクト同士のメッセージ通
> 信によって処理をしているわけですから。

うーむ。Object Oriented の、Object が曖昧なので、僕は、今の B-free を Object Oriented なOS
とは認めたくないですねぇ。
たとえば、process も SMB も、ある種の共通する性格を持っています。例を挙げると、

 1.生成できる。
 2.削除できる。
 3.Access 件を設定できる。..., etc.

そこで、VolatileObject という抽象を規定して、process も memory もその一種だとしましょう。
もし B-free がOOなら、process と SMB に対して、全く同じ API で操作ができるはずです。その
API は、VolatileObject を操作できるという API です。こう云うのを、Object Oriented というのだ
と思います。

現在の B-free は、Manager が基本であり、適切な API を利用者の方が選択して試用するという方式
で、「Object に判断させてそれ自身に適切な処理をさせる」ではなく、「やりたいことをするため
に、Object を”使う”」となっています。対象を「使う」という考え方で処理を進めていく場合、O
Oとは普通言いません。

# もっとも、Manager が自由に生成・削除できたり、
# 派生できたりすれば、OOとして見えてこなくも無い。

-Aki.

長いので二つに分けました。