2025.11.04
カテゴリ： ソフト開発日誌
Redox OS
ここからは自分で可能な試行と解釈の結果で書いていく。他の人と意見が合わないかもしれない。
まず現実的に実行可能な環境は QEMU Emulator 一択 (リンク先は Running Redox in a Virtual Machine - Redox OS) だ( Redox OS を QEMU にインストールしてみた結果をまとめたページへのリンク )。
実マシンで動く との説明は「そうかもしれないけれど」という疑問がある。試した結果、
骨董品が見つかり揃ったったとして、絶望的に Live USB Memory や CD-R(他の光学媒体も同様) の読み込みが遅い。精々 1 ～ 3Mbytes/sec の読み込み速度で live image を主記憶に読み込む。600Mbyte 程あるので、(linux で言う所の kernel + initrd) 起動だけで 3 ～ 10 分程度待たされる。それで起動すれば良い。大抵は HDD を認識したところでハングするか、起動まで漕ぎつけたとして、インストール先の HDD が見つからない。
普通の人なら、窓から投げ捨てるだろう。自分はこの時点でやる気ゲージが 50% まで落ちてしまった。
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 すらない )。
ソースコードのリンク )。
コンパイルも通ったし、実装した個別のコマンドも動くようになった。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 のソースコード
ここからは自分で可能な試行と解釈の結果で書いていく。他の人と意見が合わないかもしれない。
まず現実的に実行可能な環境は 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 のリンク )
骨董品が見つかり揃ったったとして、絶望的に Live USB Memory や CD-R(他の光学媒体も同様) の読み込みが遅い。精々 1 ～ 3Mbytes/sec の読み込み速度で live image を主記憶に読み込む。600Mbyte 程あるので、(linux で言う所の kernel + initrd) 起動だけで 3 ～ 10 分程度待たされる。それで起動すれば良い。大抵は HDD を認識したところでハングするか、起動まで漕ぎつけたとして、インストール先の HDD が見つからない。
普通の人なら、窓から投げ捨てるだろう。自分はこの時点でやる気ゲージが 50% まで落ちてしまった。
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 と入力してインストールする。
Page fault: 000000000000000C US
RFLAG: 0000000000010297
CS: 000000000000002b
RIP: 000000000061ad77
RSP: 0000000000d61e00
SS: 0000000000000023
FSBASE 000000000023e000
GSBASE 0000000000000000
KGSBASE ffff80007fc64000
RAX: 0000000000000001
RCX: 0000000000000000
RDX: 0000000000000000
RDI: 0000000000000004
RSI: 0000000000000000
R8: 0000000000000000
R9: 000000000061ad70
R10: 0000000000000001
R11: 0000000000000246
RBX: 0000000000000004
RBP: 0000000000000010
R12: 0000000000d61e60
R13: 0000000000000018
R14: 0000000000000001
R15: 0000000000000000
FP ffff80000f02fe80: PC ffffffff8007c115
FFFFFFFF8007BF40+01D5
kernel::arch::x86_shared::interrupt::exception::page::inner
FP ffff80000f02ff50: PC ffffffff80078e87
FFFFFFFF80078E50+0037
kernel::arch::x86_shared::interrupt::exception::page
0000000000000010: GUARD PAGE
RFLAG: 0000000000010297
CS: 000000000000002b
RIP: 000000000061ad77
RSP: 0000000000d61e00
SS: 0000000000000023
FSBASE 000000000023e000
GSBASE 0000000000000000
KGSBASE ffff80007fc64000
RAX: 0000000000000001
RCX: 0000000000000000
RDX: 0000000000000000
RDI: 0000000000000004
RSI: 0000000000000000
R8: 0000000000000000
R9: 000000000061ad70
R10: 0000000000000001
R11: 0000000000000246
RBX: 0000000000000004
RBP: 0000000000000010
R12: 0000000000d61e60
R13: 0000000000000018
R14: 0000000000000001
R15: 0000000000000000
FP ffff80000f02fe80: PC ffffffff8007c115
FFFFFFFF8007BF40+01D5
kernel::arch::x86_shared::interrupt::exception::page::inner
FP ffff80000f02ff50: PC ffffffff80078e87
FFFFFFFF80078E50+0037
kernel::arch::x86_shared::interrupt::exception::page
0000000000000010: GUARD PAGE
いきなり 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" の様なコンソールメッセージを出力するのかと思っていたら、沈黙をもって動作しない。
うん、ここに辿り着くまでに次のような未実装メッセージを散々見ている。
example 1: setsockopt(23, 1, 9, 0x20c7e0, 4) - unknown option
example 2: relibc getgroups(65536, Pointer { addr: 0xd5a0, metadata: 65536 }): not implemented
example 3: relibc getrlimit(7, 0x7ffffffffba8): not implemented
example 2: relibc getgroups(65536, Pointer { addr: 0xd5a0, metadata: 65536 }): not implemented
example 3: relibc getrlimit(7, 0x7ffffffffba8): not implemented
やる気ゲージ 10% down。ああ、普通に動いていない環境なんだ。
普段使いは JP keyboard なので、US keyboard 入力を強要する GUI にも不満が溜まる( keyboard driver を見ると layout は hard coding だし JP layout は stub すらない )。
ソースコードのリンク )。
コンパイルも通ったし、実装した個別のコマンドも動くようになった。test loop が回りだしてしばらくすると、kernel panic が起きる(起きなくても loop が途中で動かなくなって、UNIX で言う所の kill -HUP $pid をしないと終了しない)。できることは QEMU 毎終了するだけだ。
KERNEL PANIC: panicked at src/memory/mod.rs:954:9:
allocator-owned frames need a PageInfo, but none for [frame at 0x7ffffffffffff000]
FP ffff800016caf730: PC ffffffff80050e55
FFFFFFFF80050CD0+0185
kernel::panic::panic_handler_inner
FP ffff800016caf820: PC ffffffff8004ef39
FP ffff800016caf830: PC ffffffff800a732f
FP ffff800016caf860: PC ffffffff80075d90
FFFFFFFF80075AF0+02A0
kernel::memory::deallocate_p2frame
FP ffff800016caf8f0: PC ffffffff8001d2ae
FFFFFFFF8001CAC0+07EE
<kernel::context::memory::AddrSpace as core::ops::drop::Drop>::drop
FP ffff800016cafac0: PC ffffffff80033b1c
FFFFFFFF80033B00+001C
alloc::sync::Arc<T,A>::drop_slow
FP ffff800016cafb30: PC ffffffff80049d8f
FFFFFFFF80049720+066F
<kernel::scheme::proc::ProcScheme as kernel::scheme::KernelScheme>::close
FP ffff800016cafc40: PC ffffffff800968ea
FFFFFFFF800964B0+043A
kernel::context::file::FileDescription::try_close
FP ffff800016cafcd0: PC ffffffff80096464
FFFFFFFF800963A0+00C4
kernel::context::file::FileDescriptor::close
FP ffff800016cafd40: PC ffffffff80066baa
FFFFFFFF80066A30+017A
kernel::syscall::fs::close
FP ffff800016cafd70: PC ffffffff8006b2c3
FFFFFFFF8006AEF0+03D3
kernel::syscall::syscall
FP ffff800016cafea0: PC ffffffff8005f6ee
FFFFFFFF8005F640+00AE
__inner_syscall_instruction
FP ffff800016caff50: PC ffffffff80058693
FFFFFFFF80058650+0043
kernel::arch::x86_64::interrupt::syscall::syscall_instruction
0000000000000000: GUARD PAGE
CPU #2, CID 0xffffff7f801b7f20
NAME: /usr/bin/tr, DEBUG ID: 825
SYSCALL: close(8)
HALT
allocator-owned frames need a PageInfo, but none for [frame at 0x7ffffffffffff000]
FP ffff800016caf730: PC ffffffff80050e55
FFFFFFFF80050CD0+0185
kernel::panic::panic_handler_inner
FP ffff800016caf820: PC ffffffff8004ef39
FP ffff800016caf830: PC ffffffff800a732f
FP ffff800016caf860: PC ffffffff80075d90
FFFFFFFF80075AF0+02A0
kernel::memory::deallocate_p2frame
FP ffff800016caf8f0: PC ffffffff8001d2ae
FFFFFFFF8001CAC0+07EE
<kernel::context::memory::AddrSpace as core::ops::drop::Drop>::drop
FP ffff800016cafac0: PC ffffffff80033b1c
FFFFFFFF80033B00+001C
alloc::sync::Arc<T,A>::drop_slow
FP ffff800016cafb30: PC ffffffff80049d8f
FFFFFFFF80049720+066F
<kernel::scheme::proc::ProcScheme as kernel::scheme::KernelScheme>::close
FP ffff800016cafc40: PC ffffffff800968ea
FFFFFFFF800964B0+043A
kernel::context::file::FileDescription::try_close
FP ffff800016cafcd0: PC ffffffff80096464
FFFFFFFF800963A0+00C4
kernel::context::file::FileDescriptor::close
FP ffff800016cafd40: PC ffffffff80066baa
FFFFFFFF80066A30+017A
kernel::syscall::fs::close
FP ffff800016cafd70: PC ffffffff8006b2c3
FFFFFFFF8006AEF0+03D3
kernel::syscall::syscall
FP ffff800016cafea0: PC ffffffff8005f6ee
FFFFFFFF8005F640+00AE
__inner_syscall_instruction
FP ffff800016caff50: PC ffffffff80058693
FFFFFFFF80058650+0043
kernel::arch::x86_64::interrupt::syscall::syscall_instruction
0000000000000000: GUARD PAGE
CPU #2, CID 0xffffff7f801b7f20
NAME: /usr/bin/tr, DEBUG ID: 825
SYSCALL: close(8)
HALT
pipe line / redirect で繋いだ file descriptor の close() で問題が起きる？と言うことは、file descriptor で参照するかその操作で更新する情報の reference counter が不正操作されるか、そもそも up / down が必要な処理が抜けているか余計なのか。あれ、rust って Rc<> とか Arc<> とか有るんじゃなかったの(kernel 用に再実装するとして設計思想的に強要されるやり方では)？
ここまできてやる気ゲージは 0% になった。他にも一々 UNIX 系 command とコマンドラインの使い方が違うとか、おせっかいすぎる completion とか、不便は微塵も感じていなかったことが変わっている。変えた意図を汲めないことが多い。
rust への理解は殆どない。それでも Redox OS を実装している rust のソースコード
お気に入りの記事を「いいね！」で応援しよう
[ソフト開発日誌] カテゴリの最新記事
-
今時 Windows 98 client のための samba s… 2026.06.20
-
Rust のお勉強挫折 - ある意味で年取った… 2026.04.19
-
バックアップと復元(Windows7)のダイアロ… 2026.03.23
President
MartaTek さん
The US president raged at NATO allies over defense spending in meeting with the German chancellor， as Israel ordered its military to ‘advance’ in Lebanon
(2026.05.30 15:14:24)
【毎日開催】
15記事にいいね！で1ポイント
カレンダー
サイド自由欄
コメント新着
Aちゃん22
@ Re:Metronix model 521C 18V 0.8A 電源 - i代目 x2， i+1 代目 x1， i+2 代目 x1 で 4 台(10/06)
Toshi さん、こんにちは。 ツェナーダイ…
© Rakuten Group, Inc.
