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

キーワードサーチ

▼キーワード検索

プロフィール

Aちゃん22

フォローする

フリーページ

購入履歴

FHF24SENF3 パナソニック直管蛍光灯 24W形 3波長形昼白色 Hf形スリムパルック蛍光灯

蛍光管に "SOC24ワット" 灯具に "FHF24S･E" と書かれたデスクスタンドのランプ交換のために買いました。両… [ >> ]

NIKON EN-EL8対応互換バッテリー 600mAh☆CoolpixS8、S9【送料無料】

Coolpix S7 に使用しました。一度返品交換しています。手間ですが、充電、静止画と動画撮影、電池抜き差し… [ >> ]

新着記事一覧(全4927件)

過去の記事 >

2025.11.04

Redox OS を試してみる - 仕様説明不足・不具合でやる気ゲージがすぐに 0% になる

カテゴリ：ソフト開発日誌

Redox 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% まで落ちてしまった。

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

いきなり 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

やる気ゲージ 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

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

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

rust への理解は殆どない。それでも Redox OS を実装している rust のソースコード

お気に入りの記事を「いいね！」で応援しよう