Go to Qiita Advent Calendar Top
LoginSignup
14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 4

NRI xPalette Advent Calendar 2025

@ogwkotain株式会社野村総合研究所

【システム開発】Linux0.01をリドキュメントしてSDD開発の第一歩を踏み出してみた

Last updated at Posted at 2025-12-03

【システム開発】Linux0.01をリドキュメントしてSDD開発の第一歩を踏み出してみた

はじめに

「動くけれど中身がわからない」
古いレガシーシステムも、AIが書いた最新コードも、実は同じ悩みを抱えていないだろうか？

　そこで注目したいのが「SDD（仕様書駆動開発）」だ。仕様書を「唯一の正解」とし、そこからAIでコードを生成するこの手法は、動きを仕様として先に定義してからコードを書くため、先述の悩みを根本から解決する可能性を秘めている。
　今回は、SDDでAIをフル活用してモダナイズを行うことを目標に、「仕様書の逆生成（リドキュメント）」に挑戦する。リドキュメントの対象はLinuxの原点「Linux 0.01」とした。
「外堀から埋める」アプローチで、AIはどこまで仕様を抽出し、設計書に落とし込めるのか、挑戦してみた。

SDD開発とは？

　SDD（Specification Driven Development、仕様書駆動開発）は、仕様書(Specification)をSingle Source of Truthとする開発手法である。
AIを用いたピアプログラミングの世界を見据えた新しい開発手法として注目をされ、SDDのためのツールも開発が進んできている。

　この手法で最も重要とされるのが、仕様書である。
なぜなら、仕様に基づいてAIがコードを生成し、仕様に基づいてAIがテストケースを作成し、仕様書に基づいたシステムをAIと共に作成するからである。つまり、仕様書がこの開発手法におけるSingle Source of Truthであり、すべての基礎となる。

SDDがなぜ"今”注目されているのか

LLMの技術的な進展と、LLMを用いた従来開発手法の限界が理由として挙げられる。

  • LLM技術の進展
    • 適切な仕様書を入力として渡すことで、仕様に準拠するコードの自動生成が可能になった
    • 仕様書ベースでのテストケースの自動生成が可能になった
    • 実装をLLMが担当する前提で、人間の注力領域が「実装方法」から「仕様書作成」へシフトしていくという展望
  • Vibe Codingの限界
    • 入力プロンプトの属人性から、チーム全体での一貫性のあるコード作成・レビューの困難さ
    • プロンプトやコードに埋め込まれた暗黙知の消失
    • ドキュメント不足によるシステム保守性の低下
  • ストコンの限界
    • 保守が困難なほど複雑化したアーキテクチャを解消できない
    • コード内にある暗黙的業務知識や制約条件が抽出できない
    • モダンな技術や開発手法の導入・アーキテクチャへの移行が困難である

SDD開発において仕様書に求められる性質は何か

SDD開発において仕様書とは唯一の正解であると共に、コード生成時のプロンプト情報としても機能する。
そのため、以下のような性質を持つ仕様書が求められる。

性質 欠如したときの影響
網羅性 「書かれていないこと」に対してはAIが推論を行い、意図せぬ挙動を埋め込む。
一意性 曖昧な表現は曖昧な実装を生み出し、動作バグの温床となる。
構造化 AIがコンテキストを正確に理解できず、レイヤー構造を誤って解釈する。
具体性 自動生成されたテストケースに誤りが生じ、正しいコードを正しいと判定できなくなる。

従来の開発手法と何が違うのか

観点 従来（ウォーターフォール開発） SDD開発
読者 仕様書の主な読者は人間。
記載漏れは会話や暗黙知で補完される。		 仕様書の主な読者はAI。
曖昧さや抜け漏れはそのままバグや意図しない実装に直結する。
同期性 コードだけが更新され、仕様書は更新は後追いになりがち。
「納品前にまとめて直す」運用で陳腐化しやすい。		 「仕様書の更新後にコードを再生成する」ことを原則とする。
仕様書とコードが常に同期し、仕様書が真実である関係性が維持される。
開発の主戦場 仕様書はあくまで設計図。
エンジニアの価値は「いかに効率よく・バグなく実装するか（How）」に置かれる。		 実装（How）はAIが担当する前提。
エンジニアの価値は「何を作るか、要件をどう定義するか（What）」にシフトし、仕様を書くことが主な役割となる。

モダナイズの観点から見たSDD開発

　モダナイズ（レガシーシステムの刷新）の文脈において、SDD開発は極めて高い親和性を持つ。多くのレガシーシステムにおける最大の問題は、仕様がコードの中に埋もれ、誰も正解を知らないことである。
　SDDのアプローチでは、まず既存コードから「仕様書」をリドキュメントし、その仕様書を正として新しい技術スタックでコードを再生成する。
　単なる「code→code」の変換ではなく、「code→doc」「doc→code」というプロセスを経ることで、ブラックボックス化した業務ロジックを可視化・資産化したうえで、アーキテクチャの刷新を検証可能な状態で安全に行うことが可能になる。また、仕様書が最新で真実の状態で保たれるため、将来の保守性も向上する。

本題

SDD開発の基本となるドキュメントをGitHub Copilotで生成する

いよいよ本題である。
　ここからは実際にLinux0.01のソースコードを例に、GitHub Copilotを用いてリドキュメントを試してみる。
　使用したモデルはコンテキスト長が足りる限りはClaude Sonnet 4.5を使用し、コンテキストが足りない場合はGemini 3を使用した。
生成物に関しては、この記事の最後に一部を掲載する。

リドキュメント対象の紹介

　今回のリドキュメント対象として選んだのは、Linuxカーネルの初期バージョンであるLinux0.01である。
　選定理由は、ズバリ、「ソースコードが非常にコンパクトであり、かつシステムとしての機能を最低限備えているから」である。生成AIのコンテキストにすべてのソースファイルを突っ込むことができる数少ないシステムだからである。

項目 内容
バージョン Linux カーネル 0.01
公開年 1991年
作者 Linus Torvalds
配布形態 ソースコード一式（約1万行規模）、フロッピーディスクを想定した構成
対応アーキテクチャ Intel 80386 (i386)
主な構成ディレクトリ boot（ブートローダ／起動処理）、kernel（カーネル本体）、mm（メモリ管理）、fs（ファイルシステム）、lib（標準ライブラリ相当）、tools（ビルドツール）

リドキュメントの手順

　現行資産のリドキュメントを行う際のポイントとして、私は外堀から埋めていくことが有効であると感じている。
　外堀というのは、マクロな視点の外部仕様に該当する部分の解析から徐々にミクロな視点の内部実装の解析に入っていくイメージである。外堀から埋めていくことで、後続の詳細な解析の基礎ができ、解析の精度が向上する。
具体的には、以下の手順でドキュメントを作成していく。

1. ディレクトリ構造の解析
2. アプリケーションの概要解析
3. 処理フローの解析
4. モジュールの役割解析
5. モジュール間の依存関係解析
----ここまで来たら、設計書に起こしていく---
6. 設計書テンプレートの作成
7. 設計書の作成
8. 設計書の自己レビュー
9. 図表の作成と挿入

　では、これから実際に解析を行った手順と使用したプロンプトと成果物を紹介していく。
　コンセプトとしては、これだけ最小限のプロンプトでもドキュメントを生成できる、という点を伝えることにある。なので、プロンプトはできるだけシンプルで汎用的にしている。

実際に試す方は、この記事のプロンプトを参考にしつつ、独自のドメイン情報や構造化プロンプトを追加してみてほしい。

Linux0.01のファイルダウンロード

Linux0.01のソースコードをダウンロードし、解凍する。

wget https://www.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz
tar zxvf linux-0.01.tar.gz

1. ディレクトリ構造の解析

システムにおける一番大きな単位であるディレクト構造の解析から始める。
システムの全体像を把握することと、後続の解析の基礎情報を得ることが目的である。

このシステムについて解析をしていきます。
まず始めに、ディレクトリ構造を解析してください。
具体的には、どのディレクトリにどのようなファイルが入っていて、何の役割を果たしているかを解析してください。
解析結果はmarkdown形式で出力してください。

2. アプリケーションの解析

何をするシステムなのかを把握するために、アプリケーションの解析を行う。
今回はOSが対象ではあるが、汎用性を重視してアプリケーションとして解析を行った。

解析対象のシステムの特定を行います。
このシステムがどのような機能を提供しているかを解析してください。
具体的には、システムの名前、機能、使用方法などを解析してください。
解析結果はmarkdown形式で出力してください。

※ディレクトリ構造の解析で得られたドキュメントをコンテキストに含めて解析を行う

3. 処理フローの特定

システムがどのように動作するかを把握するために、処理フローの特定を行う。
ここから、システムの内部的な動作の解析に入っていく。

解析対象のシステムの処理フローを特定します。
このシステムがどのように動作するかを解析してください。
具体的には、システムの起動から終了までの流れを解析してください。
解析結果はmarkdown形式で出力してください。

※アプリケーションの解析までで得られたドキュメントをコンテキストに含めて解析を行う

4. モジュールの役割特定

どのようなモジュールがあり、どのような依存関係を持っているかを把握することで、プログラムファイル間の関係性を解析する。

システム全体のモジュールに関する解析を行います。
まず、どのようなモジュールが定義されているかを特定してください。
次に、各モジュールの役割や機能を解析してください。
解析結果はmarkdown形式で出力してください。

※処理フローの特定までで得られたドキュメントをコンテキストに含めて解析を行う

5. モジュール間の依存関係特定

システム全体のモジュール間の依存関係に関する解析を行う。
モジュールの依存関係を把握することで、モジュール間の結合関係を解析する。
今回はモジュールの役割特定の段階でモジュール間の依存関係まで解析が実施されたので、
依存関係に関する解析はskipした。

6. 設計書のテンプレート作成

システムの設計書を作成するためのテンプレートを作成する。組織に合ったテンプレートを用意することにより、システム間での仕様書の一貫性を保つことができる。また、仕様書のテンプレートがガイドとなり、仕様書の生成精度が向上する。今回は仕様書の生成から取り組んでみることとした。

OS向けの設計書を作成したいです。
アプリケーション向けではなく、OS向けな点に注意してください。
まずは、設計書のテンプレートを作成します。
テンプレートのレビューをしたいので、テンプレートの作成までで十分です。
作成する設計書の種別は以下です。
- 詳細設計書
- 内部設計書
- 外部設計書
- システム概要設計書

7. 設計書の作成

今までに作成した資材をすべて渡して、設計書の作成を行う。
この手順では、設計書に可能な限り意図した通りの正確な情報を記載したいことから、魔法の言葉「追加で質問があれば、質問してください。」を付与。

今までのシステム解析結果のドキュメントから設計書を作成してください。
設計書を見て同じシステムを他の言語で作り直せるようにすることが目的です。
抜け漏れがないように注意してください。
設計書のフォーマットはテンプレートファイルを参照するようにしてください。
作成する設計所は以下の4点です。
- 詳細設計書
- 内部設計書
- 外部設計書
- システム概要設計書
追加で質問があれば、質問してください。

実際に以下のような質問が返ってきた。

了解しました。Linux 0.01 を対象に、OS向けテンプレートに沿った4種類の設計書をフルスペックで起こします。

進め方の案:
os_system_design_template.md をベースに、Linux 0.01 の システム概要設計書 を作成
os_external_design_template.md をベースに、外部設計書（システムコール・シェル・FS・デバイスI/F） を作成
os_internal_design_template.md をベースに、内部設計書（メモリ/割り込み/プロセス/FS内部/ドライバ） を作成
os_detailed_design_template.md をベースに、詳細設計書（関数・アルゴリズム・データ構造レベル） を作成
4ファイルすべてを 2025_Advent 配下に出力（例: linux001_system_design.md など）
その前に、設計の粒度を合わせたいので、以下だけ確認させてください：

対象とする「実装言語」想定
「他の言語で作り直せるように」とありますが、主に意識するのはどれでしょうか？
例: C++ / Rust / Go / Zig / それとも「特定言語は意識せず、言語非依存の仕様書」でOKか
対象ハードウェアの範囲
Linux 0.01 相当の仕様として、基本は 32bit x86 (i386) 固定でよいですか？
それとも「将来 ARM/RISC-V にも移植しやすいように、アーキ依存部分と非依存部分をより明確に分離して書いてほしい」という要望はありますか？
設計書の粒度レベル
すべて「他言語でリプレイス可能レベルまで」とあるので、
システム概要設計書: 章構成はテンプレートどおり＋要件と制約をやや厚め
外部設計書: 全システムコール一覧＋引数/戻り値/エラー＋ファイル階層＋デバイスI/F を網羅
内部設計書: 全主要構造体(task_struct, super_block, inode, buffer_head, etc.)のフィールド仕様 まで書く
詳細設計書: 主な関数（schedule, fork系列, execve, do_no_page, ll_rw_block, bread, hd_interrupt, etc.）の処理フローと疑似コード をきっちり記述
というイメージで問題ないでしょうか？
上記3点について、

「言語非依存でOK」「アーキはi386固定でOK」など、簡単で構わないので方針だけ教えてください。
それを前提に、4つの設計書をまとめて生成します

以下のように回答

1. 言語非依存でOK
2. x86固定でOK
3. 設計書の粒度レベル: そのイメージで問題ない

これで無事に作成された。

8. 設計書の自己レビュー

自己レビューによって、設計書の内容に漏れや誤りがないかを確認する。
大抵の場合、何かしらが抜け落ちるので、自己レビューは必須であると考えている。

これらの設計書の情報とシステム解析結果の情報を照らし合わせて、設計書の内容に漏れや誤りがないかを確認してください。
もし漏れや誤りがあれば、設計書を修正してください。
また、修正した箇所と抜け落ちた理由を表にまとめて、報告してください。

コンテキストとしてコードも渡していたことから、

設計書の抜け落ち→解析ドキュメントの抜け落ち→コードの追加解析→解析ドキュメントの更新→設計書の更新

上記の一連の流れを自律的に行っていた。
致命的な抜け落ちはなかったが、曖昧さが残っていた部分に関して細かい修正が数点発生した。

9. 図表の作成と挿入

設計書に図表を追加することで、設計書の可読性と理解度が向上する。
2025年末時点でのAI技術では、既に複雑なマーメイド図の生成も可能になっているため、ぜひ試してみてほしい。
ただし、日本語表記はまだ苦手なようなので、英語表記指定を行うと文法修正が不要なものが出力されやすい。

詳細設計書と内部設計、外部設計にMermaid記法でフロー図を記入してください
ただし、図のラベルは英語で記入してください

考察

Linux0.01のリドキュメントを通じて、感じたことをつらつらと書き連ねてみる。

仕様書の作成は容易だが、正確性の担保が非常に難しい

今回のリドキュメントを通じて、設計書の作成自体は非常に容易であることを実感した。
一方で、作成したドキュメントの正確性、特に網羅性の担保が非常に難しいことも感じた。
成果物のレビューの手順として、ドキュメントをベースにコードを参照し、ドキュメントの正確性を検証することは量的問題はあれど、可能だと感じた。
しかし、ドキュメントの網羅性を担保するためには、ドキュメント作成の際に参照されていないコードはどこかを特定し、ドキュメントに反映させる必要がある。これは、現時点でのAI技術では非常に難しいと感じた。
AIピアログラミング時代において、コードを書く能力の重要性は相対的に低下する一方で、コードを正確に読んで理解する能力の重要性は相対的に高まると考えられる。

外堀から埋めていくアプローチの有効性

外堀から埋めていくアプローチは解析の観点だけでなく、人間がレビューする際の観点からも有効であると感じた。
レビューの際に知っておくべき前提知識は、それ以前での解析段階の成果物であるため、思考の流れを切らさずにレビューできた。
GitHub Copilotの動きを見ていくと、今後は解析のためのベストプラクティス的なプロンプトがシステムプロンプトとして提供されるようになると予想される。
この潮流の中でも、システムプロンプトの裏の思想を把握しておくことは、成果物の品質をレビューによって担保するうえでも重要だと感じた。

おわりに

今回の検証で、AIは「コードを読む」ツールとしても非常に優秀だとわかった。
ただし、考察でも触れた通り、AI任せで完璧な仕様書ができるわけではない。人間が成果物とコードを読んでレビューすることで、初めて「使える仕様書」になる。

そうして作り上げた仕様書があれば、それを正解とする仕様書駆動開発のモダナイズも可能になるだろう。

ぜひ、皆さんも手元にあるコードを題材に、現代のLLMでどこまで仕様書が書けるか、試してみてほしい。

作成した図表の一部

システムコール実行(外部設計)

デバイスファイル一覧(外部設計)

デバイスパス メジャー マイナー 種別 説明
/dev/ram 1 0 Block RAMディスク
/dev/fd0 2 0 Block フロッピーディスクドライブ0
/dev/fd1 2 1 Block フロッピーディスクドライブ1
/dev/hd0 3 0 Block ハードディスク全体 (第1ドライブ)
/dev/hd1 3 1 Block 第1パーティション
/dev/hd2 3 2 Block 第2パーティション
/dev/hd5 3 5 Block ハードディスク全体 (第2ドライブ)
/dev/tty0 4 0 Char 現在のコンソール
/dev/tty1 4 1 Char 第1コンソール
/dev/tty2 4 2 Char 第2コンソール
/dev/ttyS0 4 64 Char シリアルポート COM1
/dev/ttyS1 4 65 Char シリアルポート COM2

プロセス状態遷移図(内部設計)

プロセス生成(詳細設計)

解析結果の出力

ディレクトリ構造解析結果(一部)

ディレクトリ構造からのみでは推測できない情報を含んでいることから、インターネット上から情報を引っ張ってきている可能性はある。プロンプトの優先度的にはインターネット上からの情報は暗黙知で最も優先度が低いので、そこまで問題ないと判断。

# Linux 0.01 ディレクトリ構造解析

## 概要
Linux 0.01は、Linus Torvaldsが1991年にリリースした最初のLinuxカーネルです。このバージョンは約10,000行のコードで構成され、基本的なOSの機能を実装しています。

## ディレクトリ構造

### 📁 `/` (ルートディレクトリ)
- **Makefile**: システム全体のビルドを制御するメインMakefile
  - boot、kernel、mm、fsの各サブシステムをリンクしてImageファイル(起動可能なカーネルイメージ)を生成
  - GCCコンパイラとGASアセンブラを使用
  - 最終的な出力: `Image` (ブート可能なカーネルイメージ)

---

### 📁 `boot/` - ブートローダー
システム起動時に最初に実行されるコード群

**ファイル:**
- **boot.s**: 第1段階ブートローダー (アセンブリ)
  - BIOSによって0x7c00にロードされる
  - 自身を0x90000に移動し、システムを0x10000にロード
  - プロテクトモードに切り替えてカーネルを起動
  
- **head.s**: カーネル初期化コード (アセンブリ)
  - プロテクトモードでの最初の実行コード
  - ページングの設定
  - GDT/IDTの初期化
  - main()関数の呼び出し

**役割:** ハードウェアの初期化とカーネルの起動準備

---

システム機能解析

# Linux 0.01 システム機能解析

## システム概要

### システム名
**Linux 0.01** (リナックス バージョン 0.01)

### 開発者
Linus Torvalds (リーナス・トーバルズ)

### リリース日
1991年9月17日

### システムの性質
- **分類**: Unix系オペレーティングシステムカーネル
- **タイプ**: モノリシックカーネル
- **アーキテクチャ**: Intel 386以降 (32bit x86)
- **ライセンス**: 当初は独自ライセンス (後にGPLv2に移行)

---

## 主要機能

### 1. プロセス管理機能

#### プロセスの生成と管理
- **fork()**: プロセスの複製
  - Copy-on-Write方式でメモリを効率的に複製
  - 子プロセスは親プロセスのコピーとして生成
  - 最大64プロセス (NR_TASKS = 64)

- **execve()**: プログラムの実行
  - a.out形式の実行ファイルをサポート
  - プロセスイメージの置き換え
  - 引数と環境変数の渡し

- **exit()**: プロセスの終了
  - リソースの解放
  - 親プロセスへの終了コード通知
  - ゾンビプロセスの生成

- **wait()/waitpid()**: 子プロセスの状態待機

処理フロー解析(一部)

# Linux 0.01 処理フロー解析

## 概要
このドキュメントでは、Linux 0.01の起動から終了までの詳細な処理フローを解析します。システムがどのように初期化され、プロセスが実行され、終了するかを段階的に追跡します。

---

## 全体フロー概要図

電源投入
   ↓
BIOS起動
   ↓
MBR読み込み (boot.s)
   ↓
カーネルロード
   ↓
プロテクトモード移行
   ↓
カーネル初期化 (head.s)
   ↓
メイン処理開始 (main.c)
   ↓
システム初期化
   ↓
init プロセス起動
   ↓
シェル起動
   ↓
ユーザーコマンド実行
   ↓
プロセス終了
   ↓
システム終了

モジュール解析(一部)

# Linux 0.01 モジュール解析

## 概要
Linux 0.01は、機能ごとに明確に分離されたモジュール構造を持つモノリシックカーネルです。各モジュールは独立したディレクトリに配置され、Makefileによって管理されています。このドキュメントでは、各モジュールの詳細な役割と相互依存関係を解析します。

---
## モジュール全体構成

### ビルドアーキテクチャ
linux/
├── boot/          (ブートローダー)
├── init/          (初期化)
├── kernel/        (カーネルモジュール)  → kernel.o
├── mm/            (メモリ管理モジュール) → mm.o
├── fs/            (ファイルシステムモジュール) → fs.o
├── lib/           (ライブラリモジュール) → lib.a
├── include/       (ヘッダーファイル)
└── tools/         (ビルドツール)

最終生成物:
  boot/boot + tools/system → Image

### モジュール依存関係図
                    ┌─────────────┐
                    │   boot/     │
                    │  boot.s     │
                    │  head.s     │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │   init/     │
                    │   main.c    │
                    └──────┬──────┘
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
   ┌────▼────┐       ┌────▼────┐       ┌────▼────┐
   │ kernel/ │◄─────►│   mm/   │◄─────►│   fs/   │
   │kernel.o │       │  mm.o   │       │  fs.o   │
   └────┬────┘       └────┬────┘       └────┬────┘
        │                 │                  │
        └─────────────────┼──────────────────┘
                          │
                    ┌─────▼─────┐
                    │   lib/    │
                    │  lib.a    │
                    └───────────┘
---

## 1. boot モジュール (ブートローダー)

### 構成ファイル
- **boot.s** (512バイト - MBR)
- **head.s** (カーネルエントリポイント)

### 役割
システム起動時の最初の処理を担当

### 主要機能

#### boot.s
```assembly
機能:
- BIOSからのロード (0x7C00)
- 自身を0x90000に移動
- カーネルイメージのロード (0x10000)
- プロテクトモードへの移行
- GDT/IDTの初期設定
- A20ゲートの有効化
- 8259 PICの再プログラミング

提供する機能:
- read_it:     ディスクからカーネル読み込み
- kill_motor:  FDモーター停止
- empty_8042:  キーボードコントローラ待機

設計書

システム概要設計書(一部)

# Linux 0.01 システム概要設計書

## 1. ドキュメント情報
- **作成日**: 2025/12/01
- **作成者**: GitHub Copilot
- **バージョン**: 1.0
- **対象システム**: Linux Kernel Version 0.01

## 2. システム概要
### 2.1 開発の目的
- **目的**: UNIX互換のオペレーティングシステムを、安価なPC/AT互換機上で動作させること。
- **目標**: POSIX標準に準拠したシステムコールインターフェースを提供し、教育およびホビー用途での利用を可能にする。
- **ユースケース**:
  - シングルユーザー環境でのシェル操作
  - C言語開発環境 (GCC) の実行
  - 基本的なUNIXコマンドの実行

### 2.2 ターゲット環境
- **CPUアーキテクチャ**: Intel 80386 (i386) 以降
- **動作モード**: プロテクトモード (32bit)
- **メモリ容量**: 最低 4MB、推奨 8MB (`HIGH_MEMORY = 0x800000`)
- **ストレージ構成**:
  - ハードディスク: ST-506/IDE、最大2台、パーティション対応
  - フロッピーディスク: 720KB / 1.2MB / 1.44MB 対応
  - ルートデバイス既定値: `/dev/hda2` (`ROOT_DEV = 0x306`)
- **周辺機器**:
  - AT互換キーボード
  - VGA互換ディスプレイ
  - 8259 PIC (Programmable Interrupt Controller)
  - 8253/8254 PIT (Programmable Interval Timer)
  - CMOS RTC (Real Time Clock)

### 2.3 システムの特徴
- **カーネル種別**: モノリシックカーネル
  - プロセス管理、メモリ管理、ファイルシステム、デバイスドライバが単一のアドレス空間で動作。
- **ファイルシステム**: MINIX v1 互換
  - 最大ファイル名長: 14文字
  - 最大ファイルサイズ: 64MB
- **マルチタスク方式**: プリエンプティブ・マルチタスク
  - タイムスライス方式 (10ms単位)
  - 優先度付きラウンドロビンスケジューリング

## 3. アーキテクチャ設計
### 3.1 全体レイヤー構造
+-------------------------------------------------------+
| ユーザー空間 (User Space)                             |
|   [Shell (/bin/sh)]  [Commands (ls, cp...)]           |
|   [User Applications]                                 |
+-------------------------------------------------------+
| システムコール I/F (System Call Interface: int 0x80)  |
+-------------------------------------------------------+
| カーネル空間 (Kernel Space)                           |
| +-----------------+ +----------------+ +------------+ |
| | Process Manager | | Memory Manager | | File System| |
| | (sched, fork)   | | (paging, COW)  | | (minix fs) | |
| +-----------------+ +----------------+ +------------+ |
| +---------------------------------------------------+ |
| | Device Drivers (HD, TTY, Keyboard, Serial)        | |
| +---------------------------------------------------+ |
+-------------------------------------------------------+
| ハードウェア (Hardware: x86)                          |
|   [CPU (i386)] [RAM] [HDD] [Keyboard] [VGA]           |
+-------------------------------------------------------+

外部設計書(一部)

# Linux 0.01 外部設計書

## 1. 外部インターフェース概要
本システムは、POSIX準拠を目指したシステムコールインターフェースをアプリケーションに提供する。ユーザーはシェルを通じたコマンドラインインターフェースによりシステムを操作する。

## 2. システムコール仕様 (API)
アプリケーションは `int 0x80` 割り込みを通じてカーネル機能を呼び出す。引数はレジスタ (`ebx`, `ecx`, `edx`) を通じて渡され、戻り値は `eax` に格納される。

### 2.0 システムコール実行フロー
上部に掲載済み
### 2.1 システムコール一覧 (全67個)
| No | 名前 | 機能概要 | 引数 | 戻り値 |
|----|------|----------|------|--------|
| 0  | setup | システム初期化 (内部用) | - | - |
| 1  | exit | プロセス終了 | int status | なし |
| 2  | fork | プロセス複製 | なし | pid_t (親:子PID, 子:0) |
| 3  | read | ファイル読み込み | fd, buf, count | 読み込みバイト数 |
| 4  | write| ファイル書き込み | fd, buf, count | 書き込みバイト数 |
| 5  | open | ファイルオープン | filename, flags, mode | fd |
| 6  | close | ファイルクローズ | fd | 0 or -1 |

内部設計書(一部)

# Linux 0.01 内部設計書

## 1. メモリ管理設計
### 1.1 メモリマップ (物理メモリ)
| アドレス範囲 | 用途 | 備考 |
|--------------|------|------|
| `0x00000000` - `0x0009FFFF` | カーネルコード・データ | 640KB基本メモリ内 |
| `0x000A0000` - `0x000FFFFF` | ビデオメモリ・BIOS ROM | 予約領域 |
| `0x00100000` - `End of RAM` | ユーザー領域・バッファ | ページング管理対象 |

### 1.2 仮想メモリ管理
- **ページング方式**: 2段階ページング (Intel 386標準)
  - **Page Directory**: 1024エントリ (4KB)
  - **Page Table**: 1024エントリ (4KB)
  - **Page Size**: 4KB
- **メモリ共有**: 全プロセスが同じリニアアドレス空間 (`0` - `64MB`) を共有するが、セグメンテーション (`LDT`) により論理アドレス空間を分離する。
  - プロセス1: Base `0MB`, Limit `64MB`
  - プロセス2: Base `64MB`, Limit `64MB` ... (論理的には分離)
  - *注: Linux 0.01特有の実装。現代のLinuxとは異なる。*

### 1.3 Copy-on-Write処理フロー
スペースの関係で省略

参考記事

https://note.com/fujii_ritsuo/n/ne7d9663baec6
https://zenn.dev/beagle/articles/fd60745bc54de1
https://qiita.com/nogataka/items/b2c2cb475fa28333b56a
https://qiita.com/hisaho/items/a245c2ad5adf2ab5a409

14
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
14
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?