HN公開: DOOMを実行する自作OSカーネルの開発

 (github.com/UnmappedStack)
1 ポイント 投稿者 GN⁺ 2025-04-26 | 1件のコメント | WhatsAppで共有
  • TacOS は C とアセンブリでゼロから書かれた独自カーネルベースの UNIX ライクな趣味用 OS で、DOOM と複数の小さなユーザー空間プログラムを実行できる
  • カーネルには VFS、スケジューラ、TempFS、デバイス、コンテキストスイッチ、仮想メモリ管理、物理ページフレーム割り当て、Doom の移植版が含まれる
  • 実行環境は 実機 と Qemu エミュレータの両方をサポートし、実機では作者のノートPCでテストされている
  • ビルドと実行は git clone 後に make run で開始でき、Xorriso、Qemu、NASM、Clang のインストールが必要
  • TacOS は実用向けの完成度ではなく、趣味用の toy OS であり、複数の既知のバグがある

TacOS 概要

  • TacOS は C とアセンブリで書かれたゼロからの OS で、独自カーネルを備える
  • UNIX ライクなカーネルで構成されており、DOOM と複数の小さな ユーザー空間プログラム を実行できる
  • 主な構成要素は次のとおり
    • VFS
    • スケジューラ
    • TempFS
    • デバイス
    • コンテキストスイッチ
    • 仮想メモリ管理
    • 物理ページフレーム割り当て
    • Doom の移植版

実行環境と制限

  • TacOS は 実機 と Qemu エミュレータで実行可能
  • 実機でのテストは作者のノートPCで行われている
  • このプロジェクトは実用可能な完成形 OS ではなく、趣味用の toy OS
  • 複数の既知のバグがある

クイックスタート

  • ビルドと実行は次のコマンドで可能
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
  • make run は TacOS をビルドし、Qemu エミュレータで自動実行する
  • 必要なツールは次のとおり
    • Xorriso
    • Qemu
    • NASM
    • Clang

ビルドコマンド

  • make run: TacOS をビルドして Qemu で実行
  • make qemu: すでにビルド済みの TacOS を Qemu で実行
  • make disk: 完全なディスクイメージを tacos.iso としてビルド
  • make kernel: システムの中核である TacOS カーネル をビルド
  • make libc: 標準ライブラリをビルド
  • make userspace: ユーザー空間アプリケーションをビルド
  • make initrd: システムが起動する初期 RAM ディスクを生成
  • make lint: カーネルに対してリンタールールを実行
  • make qemu-gdb: GDB を接続した状態で TacOS を Qemu 上で実行

デバッグ

  • TacOS のテスト中に GDB をアタッチするには、make qemu-gdb を実行した後、別のターミナルから GDB のリモートターゲットに接続する
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
  • カーネルをデバッグする場合は kernel/bin/tacos を指定する
  • ユーザー空間プログラムをデバッグする場合は initrd/usr/bin/<program> を指定する

ライセンスと貢献ルール

  • TacOS は Mozilla Public License 2.0 を採用している
  • コントリビューションは歓迎されているが、pull request の前に issue を立てて変更内容を割り当ててもらう必要がある
  • 単純な誤字や文法修正だけを含む pull request はマージされない
  • コミットメッセージは [component] change 形式に従う必要がある
  • 無関係な複数コンポーネントにまたがる数千行の変更を 1 つの巨大なコミットにまとめた pull request はレビュー対象にならない

コミュニティ

  • TacOS の更新情報、OSDev プロジェクトの支援、会話のための Discord サーバー がある

関連記事

1件のコメント

 
GN⁺ 2025-04-26
Hacker Newsのコメント

  • おめでとう！誇らしいだろうし、概念実証に DOOM を選んだのもいいね。
    初心者質問ばかりで拍子抜けするかもしれないけど、これをノートPCで動かすにはどんな手順が必要なのか気になる。
    ビルドした後は、Windows PCでデュアルブートを設定するのと似たような流れになるのかな。インターネット上の見知らぬ人に、自分のコンピュータで危険なソフトウェアを動かす方法を聞いていると思うとちょっと笑える。
    こういうプロジェクトをやってみたいなら、おすすめの教材や読み物も知りたい。大学でOSや関連科目は履修したけど、電気電子専攻だったのでどれもかなり抽象的で概念中心だった。もっと具体的な資料があると嬉しいし、必ずしもx64である必要はない。

    • まったく拍子抜けなんかしないよ！自分のノートPCで動かした方法は、文字どおり ISOでUSBをフォーマットして、そのUSBから起動しただけ。
      カーネルを書いてみたいなら、まず https://osdev.wiki を見るのがおすすめで、Intel Developer Manualのような関連仕様や、自分で書くドライバの仕様も読む必要がある。
      x86以外のカーネル開発はよく知らないけど、知る限り概念はほとんど同じで、技術的な実装だけが違う。プロジェクトのREADMEにDiscordサーバーへのリンクがあり、そこには本当に賢い人たちがたくさんいて、喜んで手伝ってくれるはず。
    • 自分もまだ完成はしていないけどカーネルを書いていて、踏んだ手順をすべて文書化した。多くの人が役に立つと言ってくれたよ: https://0xc0ffee.netlify.app/osdev

  • いいね。でも君のタコスでもDOOMは動くの？
    冗談はさておき、本当に称賛に値する取り組みで、よくやった！気になるのは、TacOSを作る中で DOOMを標準的な目標のように据えていたのか、それとも最初からDOOMだけを動かす専用OSを作ることが目標だったのかということ。
    純粋な好奇心で聞いている。ほぼ30年ほど前、学びと楽しみのために、起動だけはする極端に骨組みだけのOSを作ったことがあるけど、実質的にDOOMだけを実行できてどこにでも移植可能な専用OSなら、「これDOOM動く？」ミームがさらに皮肉で面白くなりそう。
    素晴らしい仕事だし、ぜひ続けてほしい。

    • Doomだけを実行できるわけではなく、それが最近移植した マイルストーンというだけ。
      Doom自体を動かすのには、libc要件の追加も含めてだいたい1週間ほどかかったけど、その前に敷いておいた基盤作業のほうがずっと多かった。
      DoomGenericを使った。基本的に、とても移植性が高く作られたDoomのフォークだ。答えになっていればいいけど、もしかすると自分が質問を誤解しているかもしれない。

  • ゼロから作ったカーネルでいきなり DOOM まで到達するのは、最上級ハッカー認定みたいなものだね。実機で動いているのを見たら本当に嬉しいだろうし、すごく格好いい。

    • 実機で動くのはかなり嬉しい。カーネルが正確にDoomへ直接入るわけではなく、シェルにブートして、そこからDoomを実行できる構成ではある。

  • 少し横道だけど、似たようなことが気になっていた。現代のPCハードウェアで直接ブートするゲームを作ろうとする試みは多かったのだろうか。
    OS全体を起動せずに、そのままゲームへ入る方式で、昔の世代のゲーム機に似ている。単純に保つなら、Wi-Fi、Bluetooth、GPUのようなものは現代的なドライバなしでは活用しづらいだろうけど、キーボードとマウスは基本的なBIOSアクセスのようなものがあるので、かなり可能そうに見える。用語は間違っているかもしれないけど、要点が伝わればいい。

    • 広く使われていたかは分からないけど、知られている方法で、ちゃんと動く。初期のx86-16アセンブリ実験でこういうことをやったけど、最終的にはqemuより使いやすいエミュレータであるdosbox-stagingを使うために、DOSをプログラムランチャーとして使うようになった。
      ディスクI/Oに踏み込みたくないなら、大きな制約は 512バイト以下という点。実質的にプログラムをマスターブートレコードとして実行することになるからだ。もっと容量が必要なら、ディスクからLBAをいくつか読み込む必要があり、そのための割り込みもあるし、osdevにはより良い資料もある。
      それ以外では、.comファイル、通常の64KB単一セグメント制限、そしてMBR形式のブート可能プログラムの違いはかなり小さい。

  • 本当に素晴らしい仕事だ。自分にもこういうことをする実力があればいいのにと思うけど、これを成し遂げるには 仕様をたくさん読む必要があったはずで、それが自分の一番弱いところだ。
    馬鹿げた質問かもしれないけど、GPUアクセラレーションを非常に小さな形ででも使いたいとしたら、GPUドライバを作るのはどれくらい難しいのか気になる。関連ドキュメントはよく整備されていると思う？

    • それはおそらくOS開発の極限領域だと思うし、少なくとも実際に購入できるGPU向けのドライバなら、自分にもできない可能性が高い。
      QemuのエミュレートGPUはドキュメントがかなり良いので可能かもしれないけど、Nvidia GPUのようなものは文書化がひどく、最近までドキュメントが完全に非公開だった。Linuxもこの問題で苦労しているし、結局LinuxのGPUドライバを持ってきて使う趣味OS開発者も何人か見た。
      ほぼ不可能だと印を付けている作業は多くないけど、一般的なGPU向けに本当にまともな GPUドライバを書くことは、正直、自分がいつかできるようになる気がしない。

  • unmapped、こんにちは。GitHubとDiscordではThatOSDeveloperという名前を使っていて、それが自分の表示名です。TacOSでDoomを動かしたとは知らなかったけど、かなり格好いいですね。
    いくつか気になることがあります。オリジナルのDoomなのか、ディスク上にあるのかinitramfs上にあるのか、そして使っているエンジンと一緒にFreedoomを使っているのか、シェアウェア版DoomのWADを使っているのかが気になります。

    • 投稿で分かるとおり doomgenericで、このページの上部を見れば分かるように、変更はかなり少ないです。
    • Doomの移植性の高いフォークである DoomGenericを使っています。initrdからロードしたTempFS上にあり、doom1.wadを使っています。

  • とても素晴らしいけど、今は低レベルでメモリ安全な言語があるのに、なぜ安全でない言語を選んだのか気になる。セキュリティバグの大半がメモリ関連だということは、もうみんな分かっている。
    趣味プロジェクトだというのは理解しているけど、より良い代替がある状況で、なぜ 安全でない言語を退場させないのか分からない。

    • 主にCのほうがずっと単純だからで、カーネル開発では 単純さがすべてだから。
      他のプロジェクトではRustを使ったことがあるけど、カーネル開発では、安全な言語よりも、単純で読みやすい言語をずっと使いたいと感じる。

  • クラブへようこそ！ほぼ同じことをやったことがあり、製品につながることが絶対にない何かを作る 穏やかさを本当に楽しんだ。
    https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...

  • 本当に素晴らしいプロジェクトだ！TacOSでは プロセス分離とスケジューリングをどう扱っているのか気になる。

    • 仮想メモリにはページングを使って、各プロセスが自分のアドレス空間を持てるようにしている。
      PITドライバに接続された ラウンドロビンスケジューラがあり、10msごとにPITが割り込みを発生させてスケジューラが実行される。スケジューラは次のタスクを選び、前のタスクの現在状態を保存し、新しいアドレス空間へ切り替え、スタックを変更し、タスクのレジスタを復元したうえで、iretq命令でring 3のユーザーモードへ移行しながら命令ポインタへジャンプする。

  • TacOSについてもっと知りたい。複数のプログラムを同時に安全に実行するのはどう管理しているの？