Categories Books | Hard | Hardware | Linux | MCU | Misc | Publish | Radio | Repository | Thoughts | Time | UNIX | Writing | プロフィール
今日から秋休み(?)。この1週間は書籍化の作業と、新サーバー上での WiLiKi ページのセットアップにいそしむことにしよう。
数多くの読者の方々から「まだか、まだか」と催促を頂き続けている GCC プログラミング工房の書籍化だが、第一部・二部に分かれた出版になりそうである。これも一重に皆様から頂いた応援の賜物であります。あと、これは表面的には見えてこないけれども、本連載誕生から現在に至るまでサポートして頂いている、渡辺・新編集長からの強力なバックアップも多大。
さて、当初は連載記事に若干手直しを加えたものを出版するつもりでいたのだが、ここしばらく真剣に全体の構成を練り直した結果、ほとんど一から書き直すことになりそう。
なぜなら、この2年間に私自身が成長しており、今の目で 2001年7月号を見直すと、全く物足りないからだ。説明が言葉足らず、進行がギクシャク、疑問点が解明されないまま進んでいる、など何ともお恥ずかしい限り。
で、この休みの間に先頭導入部を3章分ほど一気に書き下ろす予定。プロットは次の通り。
という感じだ。今回のポイントは、第二章においてオリジナルの最小実行ファイル形式を実装する点にある。UNIX USER 上での連載記事は全体を通じて ELF を前提に解説を行っているが、実は ELF は極めて複雑な体系であり、学習の導入部にはふさわしくない。かと言って a.out は中途半端。
そこで、余計な機能を極力省き、MS-DOS の .COM 型式に相当するような、最もシンプルな実行ファイル形式を新たに作成することにした。この結果、UNIX 上のプログラムの本質は一体どこにあるのかが、より鮮明になるだろう。
さらに第4章以降において、セクション構造が登場するが、連載の中では「なぜセクションが必要になったのか」が明らかになっていない。この点についても、オリジナルの実行ファイル形式に R/W section, R/O section のふたつをサポートさせることで、その理由を体得することが可能になるだろう。
このように、基本路線は同じであるものの、書籍の中身は様変わりすることになりそう。まずは、最もシンプルな実行ファイルシステムを実装することから始めよう。
Linux における実行ファイル型式関連のソースは、先日紹介した fs/binfmt_* 関連に納められており、下調べは終わっている。プログラムがプロセスに至る仕組みは、詳解 Linux カーネルでも解説されているが、残念ながらこれだけでは不十分。結局、カーネルソースを解読した上で、実際にコードを書き下ろすしか、真に理解する方法はない。
ちなみに、このあたりになると、ネット上にさえ参考になる資料は存在しない。「雑誌や書籍は役に立たない、インターネットで検索した方がよっぽどマシ」という意見をよく耳にするが、実は「本当に知りたいこと」というのは、どこにも書かれていないのだ。自分で調べるしかないのだが、ここをクリアーできるかどうかが、良質な記事を提供できるかどうかの分かれ目だと、私は思う。
JUST FOR FUN ネタ、再び。先日、「それがぼくには楽しかったから」の第2部・第9章を読み終わってから、メモを書き留めた。実は、あれから続きは読んでいない。私的には、この本のクライマックスは第2部・8章で終わっているからだ。残りのページは、タイトルを斜め読みしただけだが、興味をそそられる内容ではなかった。
JUST FOR FUN、このたった10文字に、本書のエッセンスが凝縮されている。そして、このエッセンスは136ページで最高潮に達し、後は潮が引いていくような印象を持った。
「個体発生は系統発生を繰り返す」という有名な学説がある。これは、私達ヒトが胎内で成長する過程において、魚類・両生類・爬虫類・哺乳類という進化上の歴史を辿る事実を指している。
私はOS学習もまた、系統発生を繰り返すのではないかと思う。Linus 氏が祖父の Commodore VIC20 に始まり、Sinclair QL、IBM PC/AT と愛機を乗り換えた末に 386 上でターミナルプログラムの作成、タスクスイッチ、HDD I/O、システムコール、POSIX kernel、シェル、のコーディングを経験し、最終的に Linux 0.01 に至った経過は、まさに「系統発生の繰り返し」そのものではないだろうか?彼ほどではないが、私自身も似たような体験をしている。JUST FOR FUN を読みながら、若かりし頃の Hacking の思い出が、話の展開に折り重なるようにフラッシュバックしたものだ。
Linus 氏の過去を知り、改めてハードウェアプログラミングの重要性を再認識した。ハードウェアプログラミングとは私の造語であるが、一般的なアプリケーションプログラミングとはことなり、CPU や周辺 I/O を直接操作することを指している(FPGA の登場により、Real-hardware-programming が現実のものになってしまったが・・)。
「車輪を二度発明するな」という言葉があるが、私の立場は全く逆であり、Linus 氏と同じ軌跡を辿ることで、初めてOSの理解が可能になると考えている。また、この軌跡にこそプログラミングの醍醐味、FUN の源泉が存在することを Linus 氏は私達に伝えたかったのではなかろうか?