ふるた技工所(てっこうしょ)

Redox OSを試す。動機はごく単純に rust で書かれた OS に対する興味だ。試し始めてすぐに「使えない」という結論になった。

ここからは自分で可能な試行と解釈の結果で書いていく。他の人と意見が合わないかもしれない。

まず現実的に実行可能な環境はQEMU Emulator 一択 (リンク先は Running Redox in a Virtual Machine - Redox OS)だ(Redox OS を QEMU にインストールしてみた結果をまとめたページへのリンク)。

実マシンで動くとの説明は「そうかもしれないけれど」という疑問がある。試した結果、

• PS/2 Keyboard(US 配列限定), Mouse でのみ操作可能 (USB HID をサポートしているとの説明に対して、動いた環境は無かった)
• HDD/Optical drive の IDE 接続は ISA BUS address 空間に配置されている H/W だけ動作する(PCI Bus Configuration Register で配置情報が得られる I/F はサポートしていない。ソースコードを見る限りレジスタが Memory Mapped になっているのは非対応)
• SATA 接続の HDD は認識しないか認識・読み込み途中でハング(恐らくアクセスタイミングや手順に問題がある)
• サポートしているネットワークカードはRealtek RTL8139, Realtek RTL8168, Realtek RTL8169, Intel 82543GC, Intel 82540EM, Intel 82545EM, Intel 82573L, Intel 82579V だけだ。Realtek RTL8139, RTL8168, RTL8169 系列の OEM VID:PID や互換/クローンチップはサポートされていない(この様に判断した8139 driver と8168 driver のリンク)。Intel NIC も大雑把に e1000 系列であってもサポートは限定的だ(e1000d driver のリンク)

ほぼ骨董品になってしまった PC, Keybpard, Mouse, NIC, IDE-HDD, IDE-Optical Drive を見つけて動かすしかない。

骨董品が見つかり揃ったったとして、絶望的に Live USB Memory や CD-R(他の光学媒体も同様) の読み込みが遅い。精々 1 ～ 3Mbytes/sec の読み込み速度で live image を主記憶に読み込む。600Mbyte 程あるので、(linux で言う所の kernel + initrd) 起動だけで 3 ～ 10 分程度待たされる。それで起動すれば良い。大抵は HDD を認識したところでハングするか、起動まで漕ぎつけたとして、インストール先の HDD が見つからない。

普通の人なら、窓から投げ捨てるだろう。自分はこの時点でやる気ゲージが 50% まで落ちてしまった。

VirtualBox を普段使いしている人もいるかもしれない。VirtualBox は使えない。実マシン同様にHDD のアクセスに問題が有り(リンク先はログ、末尾に VirtualBox が検出した問題が記録されている)(VirtualBox は実マシンで起こりえる問題も厳密にエミュレーションしていると思われる)、Frame Buffer 書き込みで CPU cache 制御の問題も露見している様に見える(こちらも厳密エミュレーションなのだろう、そして実マシンで起動のための読み込みが遅いのも cache 制御に問題が有りそうだ)。



QEMU で動かすことに辿り着き、試しにプログラムを動かしてみる(リンク先は試したプログラムのソースコード)ことにした。rust で書かれた OS には失礼だとは思いつつ C 言語と bash を使う。必要な package を GUI の cosmic-terminal ウインドウで sudo pkg install git gcc13 gnu-make gnu-grep と入力してインストールする。


いきなり segmentation fault ですか(メッセージに UNIX 伝統の segmentation fault は含まれない。とは言ってもアドレス 0x000000000000000C って NULL pointer で指した構造体メンバーのアドレスだと思う)。

え？ rust で書いて segmentation fault ってあるの？なんだかなぁ... この問題は QEMU の monitor/terminal 混合ターミナル(Linux を動かすと serial port の tty になる疑似端末)で 操作すれば解決した。やる気ゲージ 20% down。

Linux 上で一通り動作確認してたのですんなりコンパイルができて、動くかと思っていたら、コマンドライン解釈に問題がでた。getopt() が動作しない。何かの error return とか、"Not Implemented" の様なコンソールメッセージを出力するのかと思っていたら、沈黙をもって動作しない。

うん、ここに辿り着くまでに次のような未実装メッセージを散々見ている。

やる気ゲージ 10% down。ああ、普通に動いていない環境なんだ。

普段使いは JP keyboard なので、US keyboard 入力を強要する GUI にも不満が溜まる(keyboard driver を見ると layout は hard coding だし JP layout は stub すらない)。

急遽 getopt() の簡易代替実装をする(ソースコードのリンク)。

コンパイルも通ったし、実装した個別のコマンドも動くようになった。test loop が回りだしてしばらくすると、kernel panic が起きる(起きなくても loop が途中で動かなくなって、UNIX で言う所の kill -HUP $pid をしないと終了しない)。できることは QEMU 毎終了するだけだ。

pipe line / redirect で繋いだ file descriptor の close() で問題が起きる？と言うことは、file descriptor で参照するかその操作で更新する情報の reference counter が不正操作されるか、そもそも up / down が必要な処理が抜けているか余計なのか。あれ、rust って Rc<> とか Arc<> とか有るんじゃなかったの(kernel 用に再実装するとして設計思想的に強要されるやり方では)？

ここまできてやる気ゲージは 0% になった。他にも一々 UNIX 系 command とコマンドラインの使い方が違うとか、おせっかいすぎる completion とか、不便は微塵も感じていなかったことが変わっている。変えた意図を汲めないことが多い。

rust への理解は殆どない。それでもRedox OS を実装している rust のソースコードを眺めて思う。rust を使えば Linus 氏程の才能が無くても安全かつ安定して動く kernel を書けるようになる訳では無いと。