Subscribed unsubscribe Subscribe Subscribe

Minix がいつの間にかすごくなっている?

MINIX マイクロカーネル

Minixって教育用のOSということとLinusをインスパイアしたということぐらいしか知らなかったけど、こんなことになっているとは。

リンク先にも書いてありますが、Minix に限らずいつもひっかかるのが「マイクロカーネルを採用しているから、モノリシックな他のOS (Linux とか Linux とか Linux とか) のカーネルのコードが◯◯万行なのにうちは◯◯千行なんだぜ」という謳い文句。モノリシックの方ってローダブルモジュールにできて、OSとしての動作に必須でない部分も勘定に入れているんだと思うんですが、それって何か違うような。

モノリシックにこだわる、というか積極的にマイクロカーネルを採用しない理由って主にメッセージングの効率とか便宜を考えてのことだと思うし、マイクロカーネルかどうかというより、モジュラーなのかどうかと、インターフェイスの一貫性だけが個人的には関心がありますね。

そういえば、どの普及型 OS でも進化の兆しが見えないなあと思うのは、新規プロセスに渡す引数のマーシャリング形式。現状は (とくに規定のない文字エンコーディングによってエンコードされた) 文字列として、なるべく人にやさしい形でマーシャルするという形をとっており、しかもそれを定めているのは主に慣習だったりで、これといったルールが見当たらない。あるのは引数の文字数制限 (バイト数制限) で、これは OS やランタイムライブラリのブートストラップなどによって決められている。

もし手を入れるとしたら、2 つの方向性があるように思う。

  1. なにか ABI を定めて構造化されたデータのまま受け渡しをするようにする。これってバリデーションをちゃんとしないと悲惨なことになりそうだ。
  2. いっそのこと XML やら YAML やら JSON やら CPON (Command-line Parameter Object Notation - 今勝手に考えた) を argv[1] に突っ込む、とか。

いずれの場合も人が使う場合にはシェルの助けを前提としていて、ヒューマンリーダブル / ライタブルな CLI 形式のパラメータから変換するということになる。

いいや、そもそもプロセスの引数って人間様用にあるのであって、プロセス同士はパイプとかメッセージキューとか共有メモリとかソケット等々で勝手にやりなさい、というのが一番プラクティカルなのか。まあ、COM (例が悪いか) もそうだし。何かこのモヤモヤとしたものがすっきりする、いい妥協点はないのだろうか。