エンジニアのジレンマ
技術は何を作ればいいかは教えてくれない。技術は如何に作ればよいかを教えるのみである。世界で最も優れたエンジニアとは、何を作ればいいか教えてくれれば何でも作ってみせると約束する者である。
優れた技術を持つはずのエンジニアが、精巧なゴミを作り続ける理由はここにある。今日のゴミはWebインタフェースを持ち、明日はAndroidアプリとなる。だが、どんなにキラキラかがやいていようと、どんなにフワフワしたおまけが付いていようと、ゴミはゴミである。
皮肉なことに、優秀なエンジニアは、自分の作っているものがゴミだと知っている。単に、ゴミ以外に何を作ればいいか知らないのだ。エンジニアのジレンマである。
技術とは如何に作るかについての知識である。知識とは形式化され体系化され教育によって学ぶことができるものである。技術と教育システムの発達した現代においては、教育によって優秀なエンジニアを育てることができるようになった。
現代に欠けているのは、何を作るかについての知識である。その知識を学んでさえいれば、系統的プロセスによって何を作ればいいか発見できるというようなものが必要とされている。そのような知識を手にすれば、エンジニアのジレンマを解決できるはずである。
MOT(Management of Technology)と呼ばれているものがそうかもしれない。少なくともそういうものを目指しているのだろう。しかし、現時点では、自信を持ってそうであると言うことはできない。MOTにはまだ実績が乏しい。
知識に頼ることができないということは、現場のエンジニアが自分で考えるしかないといいうことである。経験から学ぶしかないということである。
古代ギリシアのアルキメデスは、まさに典型的エンジニアだった。彼は、支点さえ与えられれば地球をも持ち上げてみせると約束した。だが、結局アルキメデスが地球を持ち上げることはなかった。アルキメデスはどこに支点を置けばいいか知らなかった。
技術とはてこの原理であり、何を作るかということはてこの支点である。支点なくしては、意味ある作用を及ぼすことはできない。現代のアルキメデスは、てこの原理よりはるかに進んだ技術を持ちつつも、支点を知らないがために本当に意味あるものを生み出せないでいる。
優秀なエンジニアは如何に作ればいいか知っている。しかし、エンジニアの評価は、知識の量によって計られるものではない。どれだけ価値あるものを生み出したかによって計られる。エンジニアとは社会を豊かにする存在であるはずだ。
エンジニアは技術を学ぶことに満足してはいけない。技術を学ぶと同時に、どこに支点を置けばいいか考えなければならない。おそらく、アルキメデスはどこに支点を置けば地球を持ち上げることができるか考えたのではないか。実験もしたかもしれない。良い結果は残せなかった。しかし、アルキメデスを笑うことはできない。
皮肉なことに、優秀なエンジニアは、自分の作っているものがゴミだと知っている。単に、ゴミ以外に何を作ればいいか知らないのだ。エンジニアのジレンマである。
技術とは如何に作るかについての知識である。知識とは形式化され体系化され教育によって学ぶことができるものである。技術と教育システムの発達した現代においては、教育によって優秀なエンジニアを育てることができるようになった。
現代に欠けているのは、何を作るかについての知識である。その知識を学んでさえいれば、系統的プロセスによって何を作ればいいか発見できるというようなものが必要とされている。そのような知識を手にすれば、エンジニアのジレンマを解決できるはずである。
MOT(Management of Technology)と呼ばれているものがそうかもしれない。少なくともそういうものを目指しているのだろう。しかし、現時点では、自信を持ってそうであると言うことはできない。MOTにはまだ実績が乏しい。
知識に頼ることができないということは、現場のエンジニアが自分で考えるしかないといいうことである。経験から学ぶしかないということである。
古代ギリシアのアルキメデスは、まさに典型的エンジニアだった。彼は、支点さえ与えられれば地球をも持ち上げてみせると約束した。だが、結局アルキメデスが地球を持ち上げることはなかった。アルキメデスはどこに支点を置けばいいか知らなかった。
技術とはてこの原理であり、何を作るかということはてこの支点である。支点なくしては、意味ある作用を及ぼすことはできない。現代のアルキメデスは、てこの原理よりはるかに進んだ技術を持ちつつも、支点を知らないがために本当に意味あるものを生み出せないでいる。
優秀なエンジニアは如何に作ればいいか知っている。しかし、エンジニアの評価は、知識の量によって計られるものではない。どれだけ価値あるものを生み出したかによって計られる。エンジニアとは社会を豊かにする存在であるはずだ。
エンジニアは技術を学ぶことに満足してはいけない。技術を学ぶと同時に、どこに支点を置けばいいか考えなければならない。おそらく、アルキメデスはどこに支点を置けば地球を持ち上げることができるか考えたのではないか。実験もしたかもしれない。良い結果は残せなかった。しかし、アルキメデスを笑うことはできない。
Microsoftに捧ぐ
理論的にはソフトウェアが壊れるということはない。長く使っているうちにビットがすり減ってしまうということはあり得ない。何かがうまく動かないのは、はじめから壊れていたのだ。それにも関わらず、世界中のプログラマが、ソフトウェアが壊れていくさまを目撃する。昨日までうまく動いていたものが、今日はコアを吐く。
バグを見つけたら修正しなければならない。しかし、そのバグフィックス自体が、新たなバグを持ち込む可能性がある。したがって、ソフトウェアにはメンテナンスが必要である。このメンテナンスには終わりはない。ソフトウェアは「リリースしたら終わり」の製品ではない。
ソフトウェアベンダーは植木屋と同じである。植木屋は、植木を「リリースしたら終わり」ではない。何十年、ときには何百年も成長し続けるという植物の性質上、植木にも終わりのないメンテナンスが必要である。この点では、日本の植木職人もヨーロッパの庭師も同じである。
Microsoftこそ真の植木職人である。あるいは庭師である。来年には、Windows XPのサポートが終わる。Microsoftは、2001年発売のWindows XPを実に13年間メンテナンスし続けたことになる。変化の早いソフトウェアの世界での13年は、植物の世界では300年にも400年にも相当する。
私のLinuxエンジニアとしての仕事も、まさしく植木職人のそれである。Linuxカーネルは、日々成長する巨大な論理の植物である。日々の成長は小さくとも、月日の流れの中でダイナミックに成長する。私は植木職人として、あちこちにパッチを当て、Linuxカーネルの剪定を行う。
先日、カーネル2.6.9についての問い合わせを受けた。ファイルシステムのバグを踏んだかどうか調べて欲しいというものだった。さっそくカーネル2.6.9で現象が再現するかどうか調べようとした。驚いたことに、最新のgccでは、もはやカーネル2.6.9をビルドすることができなくなっていた。カーネル2.6.9のリリースは2004年である。
MicrosoftはWindowsのすべてをコントロールできる立場にあるので、長期間のメンテナンスを行いやすいのかもしれない。そうだとしても13年は尊敬に値する。
業界のもう一人の巨人であるAppleはどうか？ OS Xのサポートを数年で打ち切ってしまうのは、花屋が切り花を売るのと同じである。切り花は、買ってから1週間はその美しさを楽しむことができる。しかしその後は、次の花に取って代わられる。Appleの花は常に美しいが、それは去年の花ではない。
90年代はMicrosoftの天下だった。しかし、ここ最近はMicrosoftを侮る声が多く聞こえる。Microsoftの製品は、Windows XPの背景のように何の変哲もない芝生に見えるかもしれない。しかし、何の変哲もない芝生はよく手入れされた芝生である。芝生には2種類しかない。よく手入れされた何の変哲もない芝生か、手入れのされていない茶色い枯れた芝生かである。
バグを見つけたら修正しなければならない。しかし、そのバグフィックス自体が、新たなバグを持ち込む可能性がある。したがって、ソフトウェアにはメンテナンスが必要である。このメンテナンスには終わりはない。ソフトウェアは「リリースしたら終わり」の製品ではない。
ソフトウェアベンダーは植木屋と同じである。植木屋は、植木を「リリースしたら終わり」ではない。何十年、ときには何百年も成長し続けるという植物の性質上、植木にも終わりのないメンテナンスが必要である。この点では、日本の植木職人もヨーロッパの庭師も同じである。
Microsoftこそ真の植木職人である。あるいは庭師である。来年には、Windows XPのサポートが終わる。Microsoftは、2001年発売のWindows XPを実に13年間メンテナンスし続けたことになる。変化の早いソフトウェアの世界での13年は、植物の世界では300年にも400年にも相当する。
私のLinuxエンジニアとしての仕事も、まさしく植木職人のそれである。Linuxカーネルは、日々成長する巨大な論理の植物である。日々の成長は小さくとも、月日の流れの中でダイナミックに成長する。私は植木職人として、あちこちにパッチを当て、Linuxカーネルの剪定を行う。
先日、カーネル2.6.9についての問い合わせを受けた。ファイルシステムのバグを踏んだかどうか調べて欲しいというものだった。さっそくカーネル2.6.9で現象が再現するかどうか調べようとした。驚いたことに、最新のgccでは、もはやカーネル2.6.9をビルドすることができなくなっていた。カーネル2.6.9のリリースは2004年である。
MicrosoftはWindowsのすべてをコントロールできる立場にあるので、長期間のメンテナンスを行いやすいのかもしれない。そうだとしても13年は尊敬に値する。
業界のもう一人の巨人であるAppleはどうか？ OS Xのサポートを数年で打ち切ってしまうのは、花屋が切り花を売るのと同じである。切り花は、買ってから1週間はその美しさを楽しむことができる。しかしその後は、次の花に取って代わられる。Appleの花は常に美しいが、それは去年の花ではない。
90年代はMicrosoftの天下だった。しかし、ここ最近はMicrosoftを侮る声が多く聞こえる。Microsoftの製品は、Windows XPの背景のように何の変哲もない芝生に見えるかもしれない。しかし、何の変哲もない芝生はよく手入れされた芝生である。芝生には2種類しかない。よく手入れされた何の変哲もない芝生か、手入れのされていない茶色い枯れた芝生かである。
『Operating System Design: The Xinu Approach, Linksys Version』を読んだ
XINU（"XINU is Not UNIX"の略）オペレーティングシステムの開発について述べた優れた本。＜中略＞この本はオペレーティングシステム概論の授業の副読本としてうってつけで、UNIXカーネルの授業でLionsのテキストと一緒に使っても良いくらいだ。（『Life with UNIX』p.127）この記述は本書の初版本に関するもので、LSI 11というPDP-11をワンチップ化したハードウェアを対象に書かれたものである。Amazonで調べてみると、本書はその後、PC版やMac版が出ていたようである。しかし、長いこと絶版となっていた。
ところが最近、Linksys（今はCISCO？）のEL 2100LというというMIPSアーキテクチャのルータ向けに書き直された版が出ていることを知った。このルータを選んだ理由として、安価で入手しやすいことと、シリアルを備えていることが本書で述べられている。日本だと、「ブロードバンドルータ」と言って家電量販店で2万円くらいで売られている類のものではないかと思う。
XINUは組込みOSとされている。今や組込み機器でもLinuxやBSDが動く時代なのでその定義は曖昧であるが、例えばMINIXと比較すると、以下の特徴がある：
MINIX本では後ろ半分に付録としてソースコードを載せていたが、本書は関数1つ毎に解説とソースコードが交互に記載されている。したがって、MINIX本のように本文とソースコードを行ったり来たりする必要はない。シーケンシャルに読める。また、小さいながらもUDP/IPプロトコルスタックも実装されている。
本書を読んだ感想だが、OSというのは、本当にまったく単なる巨大なCプログラムに過ぎない。これは、MINIX本を読んだときにも感じたことである。XINUの実装を読むことで、更にその思いを強くした。
かつては、OSには何か魔法のようなものがあると思っていた。並行プロセスやファイルシステムなど、まさに現代の魔法だった。しかし、その実装を見てみれば、何の魔法もないのだ。アーキテクチャに関わるところも、割り込み処理とブートストラップの一部だけである。そして、OSの実装言語としてのCのスジの良さ。実行環境としてスタックさえ準備してやれば、後はおなじみのCの世界である。
『Life with UNIX』にもある通り、本書はOSの授業の副読本として最適だと思う。例えば、アーキテクチャはパタヘネでMIPSを学べば、本書のアーキテクチャ依存部分もよくわかるだろう。
大人になってから、「学生時代にこの本を読んでいたら、違った未来になっていたかも」と思わせる本に出会うことがある。本書もそのひとつだ。OSに魔法などない。
忍び寄る全体主義
私が三菱電機を辞めた理由のひとつは、組織のもつ全体主義的傾向を嫌ってのことだった。全体主義とは、皆が同じ考えをもつことではない。そんなことは不可能だ。全体主義とは、皆が同じ考えをもつことを強制することである。従って、全体主義のもとでは、人は皆と同じ考えを持っているふりをするようになる。
ひとつ象徴的な例がある。私のいた事業所では、改善活動が行われていた。いわゆる「カイゼン」活動である。製造業なら、どこでもやっていると思う。職員全員について、改善のノルマが課せられていた。技術者も、事務職員も、現場の職人も例外は認められない。通常は1月に1件以上だった。
どういうわけか、改善の効果は、節約時間によって計られることになっていた。そして、年度ごとにトータルの節約時間が定められ、各セクションにその時間が割り当てられた。この時間は最低の基準とされた。
誰の目から見ても、この改善活動は馬鹿げていた。一人毎月数十時間を節約する方法を考えだすことは、不可能とは言わないまでも、通常業務の中でできることではなかった。その結果どうなったか？ 皆、改善したふりをするようになった。
ソフトウェアのセクションでは、単体テストの自動化などはよく使われる手だった。単体テストを自動化したふりをして、時間と品質を改善したことにするのだ。嘘の報告をしているのではない。実際にテストは自動化されている。ただし、その効果を見積もるところで「ふりをする」。
年度末に提出する報告書の上では、莫大な時間が節約されているはずだった。毎年のようにテストが自動化され、このままではテストの工数がマイナスになるのではないかと思われるほどだった。しかし、皆、本当は何も改善されていないことを知っていた。毎日残業し、デバッグする自分が一番良く知っているのだ。
ちなみに、改善の内容については、一応の審査はされているようである。一度、毎月の報告書に、「陶器のマグカップから側面が魔法瓶でできているマグカップに変更することで、長時間美味しいコーヒーが飲めるようになり、作業が捗るようになった」と書いたことがある。改善の委員に、さすがにそれはダメだと言われた。
私は、ここで改善活動そのものを批判したいわけではない。改善活動は必要だと思っている。実際、優れた改善のアイディアというものは存在する。私が批判したいのは、効果がないとわかっているのに、それに異を唱えることを許さない全体主義的な空気である。
これは、三菱だけでなく、苦境に陥っている日本企業すべてに言えることではないか？ かつての成功体験にしがみつき、無意味とわかっていることを続けているのではないか？
誰も「改善はインチキだ」とは言わない。私は言えなかった。もちろん、改善に異を唱えたからといって収容所に送られるわけではない。せいぜい、「害のない」ポジションに異動になるだけだろう。
多くの大企業が大量リストラを行なっている。リストラされた人には気の毒だが、これが日本企業にとっての「終戦」になることを期待している。
ひとつ象徴的な例がある。私のいた事業所では、改善活動が行われていた。いわゆる「カイゼン」活動である。製造業なら、どこでもやっていると思う。職員全員について、改善のノルマが課せられていた。技術者も、事務職員も、現場の職人も例外は認められない。通常は1月に1件以上だった。
どういうわけか、改善の効果は、節約時間によって計られることになっていた。そして、年度ごとにトータルの節約時間が定められ、各セクションにその時間が割り当てられた。この時間は最低の基準とされた。
誰の目から見ても、この改善活動は馬鹿げていた。一人毎月数十時間を節約する方法を考えだすことは、不可能とは言わないまでも、通常業務の中でできることではなかった。その結果どうなったか？ 皆、改善したふりをするようになった。
ソフトウェアのセクションでは、単体テストの自動化などはよく使われる手だった。単体テストを自動化したふりをして、時間と品質を改善したことにするのだ。嘘の報告をしているのではない。実際にテストは自動化されている。ただし、その効果を見積もるところで「ふりをする」。
年度末に提出する報告書の上では、莫大な時間が節約されているはずだった。毎年のようにテストが自動化され、このままではテストの工数がマイナスになるのではないかと思われるほどだった。しかし、皆、本当は何も改善されていないことを知っていた。毎日残業し、デバッグする自分が一番良く知っているのだ。
ちなみに、改善の内容については、一応の審査はされているようである。一度、毎月の報告書に、「陶器のマグカップから側面が魔法瓶でできているマグカップに変更することで、長時間美味しいコーヒーが飲めるようになり、作業が捗るようになった」と書いたことがある。改善の委員に、さすがにそれはダメだと言われた。
私は、ここで改善活動そのものを批判したいわけではない。改善活動は必要だと思っている。実際、優れた改善のアイディアというものは存在する。私が批判したいのは、効果がないとわかっているのに、それに異を唱えることを許さない全体主義的な空気である。
これは、三菱だけでなく、苦境に陥っている日本企業すべてに言えることではないか？ かつての成功体験にしがみつき、無意味とわかっていることを続けているのではないか？
まるで戦時中の日本軍のようだ。最初の神風特攻隊が成功を収めたという理由だけで、効果を挙げられなくなった後も飛行機による体当たりを続けた。（人道的問題はおいておくとしても）特攻隊の効果に疑問を呈することはタブーだった。日本軍が最終的にどうなったかは、よく知られるところである。結局、日本人のメンタリティとはこの程度のものかと思うと残念である。
誰も「改善はインチキだ」とは言わない。私は言えなかった。もちろん、改善に異を唱えたからといって収容所に送られるわけではない。せいぜい、「害のない」ポジションに異動になるだけだろう。
多くの大企業が大量リストラを行なっている。リストラされた人には気の毒だが、これが日本企業にとっての「終戦」になることを期待している。
LispでOSを書く
（このエントリは、Lisp Advent Calendar 2012 の22日目である）
ELIS復活祭のとき、ELISのTCP/IPプロトコルスタックを書いたという方とお話する機会があった。ELISのプロトコルスタックはもちろんLispで書かれていた。その方がおっしゃるには、「C言語はよい。BSDからソースコードを持ってくればいいのだから。しかし、Lispで書かれたプロトコルスタックなどなかった。自分で書くしかなかった」ということだった。それにしても、LispでOSを書くというのは、いったいどんな感じなのだろう？
OS記述言語としてのLisp
UnixがCで書かれて以来、OSは、伝統的にCとその派生言語で書かれることになった。BSDやLinuxを含むUnix-likeなシステムはもちろんCで書かれている。Windows NTはC++を使っている。BeOSもC++で書いたし、MacOS XはObjective-Cを使っているのかもしれない。もしかすると、IBMのメインフレームなどでは事情が異なるのかもしれない。
Cとその仲間たちは、いわゆる高級言語の中でも抽象化のスペクトルのだいぶ下の方に位置している。つまり、ビットを操作するような処理が得意なのだ。だから、デバイスのレジスタを直接叩くような処理はCの得意とするところだ。
OSを構成するサブシステムの中でも、プロトコルスタックやファイルシステムは、デバイスを叩くというよりは、ある種のロジックを実装するものだ。80年代から90年代にかけて研究されたマイクロカーネルでは、これらのサブシステムはユーザプロセスとして実現されていた。
ソフトウェア工学の言葉を使うなら、OSのコア（マイクロカーネル）はデバイスへアクセスする「メカニズム」を提供する。上位のサブシステムは、そのデバイスをどのように使うか（例えば、ファイルシステムをどう構成するか）という「ポリシー」を実装する。
複雑なロジックを実装するためには、できるだけ抽象化のレベルの高い言語を使うべきだ。そして、もっとも抽象化のレベルの高い言語（のひとつ）はLispである。したがって、OSのサブシステムも、ある部分はELISのようにLispで書いてもいいはずだ。
FUSE + libfuse + Gauche + c-wrapper
LispでOSのサブシステムを書くというのがどんな感じなのか、試してみる方法をご紹介したい。私はCommon LispよりもSchemeの方が慣れているので、Gaucheを使うことにしよう。
1から新しいOSを設計するのは、楽しいかもしれないが時間もかかる。Linuxには、FUSE(Filesystem in Userspace)という、ファイルシステムをユーザ空間で実装するための仕組みがある。この仕組みを使って、Gaucheでファイルシステムを書いてみたい。
FUSEにつて簡単に説明しよう。Linuxカーネルは複数のファイルシステムを持っている。ext3, ext4, btrfsなどなどだ。それぞれのファイルシステムの開発者のために、カーネルとファイルシステムとの間に標準的なインタフェースが決まっている。このインタフェースをユーザ空間からアクセスできるようにする仕組みがFUSEだ。
最近のLinuxカーネルなら、FUSEは標準で組み込まれている。/dev/fuseがカーネルへのインタフェースだ。基本的には、普通のファイルアクセスのシステムコールを使って/dev/fuseを操作すればよいのだが、これをもう少し簡単に行うためのライブラリとして、libfuseがある。
libfuseはCのライブラリだ。libfuseをGaucheで使うにはCへのバインディングを書けばよいのだが、もっと簡単な方法は…そう、魔法のc-wrapperである。
hellofs (The Hello Filesystem)
ストレージを操作する本物のファイルシステムではなく（これは大仕事だ）、偽物のファイルシステム（Pseudo Filesystem）を実装してみる。これは、/procや/sysの一種と考えてよい。このファイルシステムは、FUSEのサンプルプログラムをほぼそのままSchemeで書きなおしたものだ（若干の手抜きをしたので、あまりいい例ではないかもしれない）。
FUSEを使ってストレージを操作するようなファイルシステムを作りたいのなら、デバイスノードを読み書きすればよい。また、ユーザ空間でできることは何でもできる。例えば、EvernoteやGoogle Driveにアクセスするようなファイルシステムを作ることもできるはずだ。
OSのカーネルはますます大きく複雑になっている。Unixの第6版のソースコードは、印刷したものをブリーフケースで楽に持ち歩くことができるほど小さかった。今日のLinuxのソースコードを印刷して持ち歩くことは、不可能ではないが紙の無駄である。
Unix第6版の時代からプログラミング言語の世界は大きく進歩した（もちろんLispはUnix第6版の時代から存在したのだが）。ところが、今日のOS開発者は、これら進歩的プログラミング言語の恩恵に与っていない。
そろそろ、OS開発にも、次の世代のプログラミング言語を使ってもよいのではないかと思う。ELISは商業的には成功しなかった。しかし、ELISの開発過程で多くの知識が蓄積されたはずだ。（非常に失礼な言い方だが）ELISの開発者がまだ生きている今こそ、そのチャンスである（失礼しました）。
ELIS復活祭のとき、ELISのTCP/IPプロトコルスタックを書いたという方とお話する機会があった。ELISのプロトコルスタックはもちろんLispで書かれていた。その方がおっしゃるには、「C言語はよい。BSDからソースコードを持ってくればいいのだから。しかし、Lispで書かれたプロトコルスタックなどなかった。自分で書くしかなかった」ということだった。それにしても、LispでOSを書くというのは、いったいどんな感じなのだろう？
OS記述言語としてのLisp
UnixがCで書かれて以来、OSは、伝統的にCとその派生言語で書かれることになった。BSDやLinuxを含むUnix-likeなシステムはもちろんCで書かれている。Windows NTはC++を使っている。BeOSもC++で書いたし、MacOS XはObjective-Cを使っているのかもしれない。もしかすると、IBMのメインフレームなどでは事情が異なるのかもしれない。
Cとその仲間たちは、いわゆる高級言語の中でも抽象化のスペクトルのだいぶ下の方に位置している。つまり、ビットを操作するような処理が得意なのだ。だから、デバイスのレジスタを直接叩くような処理はCの得意とするところだ。
OSを構成するサブシステムの中でも、プロトコルスタックやファイルシステムは、デバイスを叩くというよりは、ある種のロジックを実装するものだ。80年代から90年代にかけて研究されたマイクロカーネルでは、これらのサブシステムはユーザプロセスとして実現されていた。
ソフトウェア工学の言葉を使うなら、OSのコア（マイクロカーネル）はデバイスへアクセスする「メカニズム」を提供する。上位のサブシステムは、そのデバイスをどのように使うか（例えば、ファイルシステムをどう構成するか）という「ポリシー」を実装する。
複雑なロジックを実装するためには、できるだけ抽象化のレベルの高い言語を使うべきだ。そして、もっとも抽象化のレベルの高い言語（のひとつ）はLispである。したがって、OSのサブシステムも、ある部分はELISのようにLispで書いてもいいはずだ。
FUSE + libfuse + Gauche + c-wrapper
LispでOSのサブシステムを書くというのがどんな感じなのか、試してみる方法をご紹介したい。私はCommon LispよりもSchemeの方が慣れているので、Gaucheを使うことにしよう。
1から新しいOSを設計するのは、楽しいかもしれないが時間もかかる。Linuxには、FUSE(Filesystem in Userspace)という、ファイルシステムをユーザ空間で実装するための仕組みがある。この仕組みを使って、Gaucheでファイルシステムを書いてみたい。
FUSEにつて簡単に説明しよう。Linuxカーネルは複数のファイルシステムを持っている。ext3, ext4, btrfsなどなどだ。それぞれのファイルシステムの開発者のために、カーネルとファイルシステムとの間に標準的なインタフェースが決まっている。このインタフェースをユーザ空間からアクセスできるようにする仕組みがFUSEだ。
最近のLinuxカーネルなら、FUSEは標準で組み込まれている。/dev/fuseがカーネルへのインタフェースだ。基本的には、普通のファイルアクセスのシステムコールを使って/dev/fuseを操作すればよいのだが、これをもう少し簡単に行うためのライブラリとして、libfuseがある。
libfuseはCのライブラリだ。libfuseをGaucheで使うにはCへのバインディングを書けばよいのだが、もっと簡単な方法は…そう、魔法のc-wrapperである。
hellofs (The Hello Filesystem)
ストレージを操作する本物のファイルシステムではなく（これは大仕事だ）、偽物のファイルシステム（Pseudo Filesystem）を実装してみる。これは、/procや/sysの一種と考えてよい。このファイルシステムは、FUSEのサンプルプログラムをほぼそのままSchemeで書きなおしたものだ（若干の手抜きをしたので、あまりいい例ではないかもしれない）。
#!/usr/bin/env goshマウントすると、マウントポイントにhelloというファイルが現れる。このファイルにはお馴染みの文字列が格納されている。
# hellofs.scm (The Hello Filesystem)
(use gauche.uvector)
(use c-wrapper)
(c-load "fuse.h"
:cppflags "-DFUSE_USE_VERSION=26"
:cppflags-cmd "pkg-config --cflags fuse"
:import '(fuse_operations
fuse_main_compat2
fuse_main
NULL)
)
(c-load "stdio.h")
(c-load "string.h")
(c-load "errno.h")
(c-load "fcntl.h")
(c-load-library "libfuse")
(define hello-path "/hello")
(define hello-str "Hello world!\n")
(define (hello-getattr path stbuf)
(memset stbuf 0 (c-sizeof (c-struct 'stat)))
(cond ((string=? (castpath) "/")
(set! (ref stbuf 'st_mode) (logior S_IFDIR #o755))
(set! (ref stbuf 'st_nlink) 2)
0)
((string=? (castpath) hello-path)
(set! (ref stbuf 'st_mode) (logior S_IFREG #o444))
(set! (ref stbuf 'st_nlink) 1)
(set! (ref stbuf 'st_size) (string-length hello-str))
0)
(else (- ENOENT))))
(define (hello-readdir path buf filler offset fi)
(if (not (string=? (castpath) "/"))
(- ENOENT)
(begin (filler buf "." NULL 0)
(filler buf ".." NULL 0)
(filler buf ((#/^\/(.*)$/ hello-path) 1) NULL 0)
0)))
(define (hello-open path fi)
(if (not (string=? (castpath) hello-path))
(- ENOENT)
(if (not (= (logand (ref fi 'flags) 3) O_RDONLY))
(- EACCESS)
0)))
(define (hello-read path buf size offset fi)
(memcpy buf hello-str (string-length hello-str))
(string-length hello-str))
(define hello-operators (make (c-struct 'fuse_operations)))
(set! (ref hello-operators 'getattr) hello-getattr)
(set! (ref hello-operators 'readdir) hello-readdir)
(set! (ref hello-operators 'open) hello-open)
(set! (ref hello-operators 'read) hello-read)
(define (main args)
(fuse_main (length args)
args
(ptr hello-operators)
NULL
))
# mkdir /tmp/helloマウントするときに、シングルスレッドモード（-sオプション）を指定することに注意して欲しい。libfuseは、その中で新たなスレッドを生成する。このスレッドはGaucheのスレッドではないので、この中からSchemeの関数をコールバックすることはできない。
# ./hellofs.scm /tmp/hello -d -s
...
# ls /tmp/hello
hello
# cat /tmp/hello/hello
Hello world!
FUSEを使ってストレージを操作するようなファイルシステムを作りたいのなら、デバイスノードを読み書きすればよい。また、ユーザ空間でできることは何でもできる。例えば、EvernoteやGoogle Driveにアクセスするようなファイルシステムを作ることもできるはずだ。
＊ ＊ ＊
Unix第6版の時代からプログラミング言語の世界は大きく進歩した（もちろんLispはUnix第6版の時代から存在したのだが）。ところが、今日のOS開発者は、これら進歩的プログラミング言語の恩恵に与っていない。
そろそろ、OS開発にも、次の世代のプログラミング言語を使ってもよいのではないかと思う。ELISは商業的には成功しなかった。しかし、ELISの開発過程で多くの知識が蓄積されたはずだ。（非常に失礼な言い方だが）ELISの開発者がまだ生きている今こそ、そのチャンスである（失礼しました）。
豊かな社会
私の母校は、工学部のみの小さな単科大学だ。工学部のみの大学であっても、いわゆる一般教養の授業がある。そのための常勤の教員もいる。特に人文社会系の講義のことを、私たちは単に「社会系」と呼んでいた。
私たちにとって、「社会系」の授業は悩みの種だった。これらの単位が、進級のための条件になっていたからだ。私たちは、エンジニアリングを学ぶために大学へ入った。そのために授業料も払った。確かに西洋思想史は興味深いかもしれないが、エンジニアリングとの接点を見出すことはできなかった。
大人になってから、「あの時もっと勉強しておけばよかった」と思わない人はいない。私もその例に漏れない。30歳を過ぎて思うには、もっと真面目に「社会系」の勉強をしておけばよかったのである。
実は、エンジニアリングと「社会系」は密接に関係していた。なぜなら、エンジニアリングとは、社会を豊かにする方法だからだ。学生時代の私は、エンジニアリングの方法論にばかり捕らわれ、その目的が見えていなかった。
19世紀の経済学者は未来を悲観した。保守主義者もマルクス主義者も、産業革命の行き着く先はユートピアではないという点では意見が一致していた。しかるに、二つの世界大戦を挟み、ヨーロッパ、アメリカ、日本を含む国々には、豊かな社会が誕生した。これらの国々の共通点は、エンジニアがたくさん住んでいるということだ。
失われた10年だか20年だか知らないが、日本企業が不調である。パナソニックが赤字という。シャープも赤字という。任天堂でさえ赤字という。日本の製造業は軒並み「オワコン」と言われる。どうしてしまったか？
日本の製造業も、学生時代の私と同様、方法論にばかり捕らわれ、社会を豊かにするという当たり前の目的が見えなくなっているように思う。私も、ついこの間まで日本の製造業に身をおいていたのでよくわかる。もっとも、彼らが捕らわれている方法論は、経営学のそれであるようだ。
何をもって社会の豊かさとするかは難しい。今年のはじめに、ロボット掃除機のルンバを買った。まるでSFの世界にいるようだった。ハインラインの『夏への扉』に出てくる家事ロボットのようだった。私の生活は豊かになった。
今年ももう終わりだ。毎年、その年のテーマを設定することにしている。来年のテーマは「社会系」にしようと思っている。今年のうちに、古本屋行きを免れた教科書を発掘しなければならない。
私たちにとって、「社会系」の授業は悩みの種だった。これらの単位が、進級のための条件になっていたからだ。私たちは、エンジニアリングを学ぶために大学へ入った。そのために授業料も払った。確かに西洋思想史は興味深いかもしれないが、エンジニアリングとの接点を見出すことはできなかった。
大人になってから、「あの時もっと勉強しておけばよかった」と思わない人はいない。私もその例に漏れない。30歳を過ぎて思うには、もっと真面目に「社会系」の勉強をしておけばよかったのである。
実は、エンジニアリングと「社会系」は密接に関係していた。なぜなら、エンジニアリングとは、社会を豊かにする方法だからだ。学生時代の私は、エンジニアリングの方法論にばかり捕らわれ、その目的が見えていなかった。
19世紀の経済学者は未来を悲観した。保守主義者もマルクス主義者も、産業革命の行き着く先はユートピアではないという点では意見が一致していた。しかるに、二つの世界大戦を挟み、ヨーロッパ、アメリカ、日本を含む国々には、豊かな社会が誕生した。これらの国々の共通点は、エンジニアがたくさん住んでいるということだ。
失われた10年だか20年だか知らないが、日本企業が不調である。パナソニックが赤字という。シャープも赤字という。任天堂でさえ赤字という。日本の製造業は軒並み「オワコン」と言われる。どうしてしまったか？
日本の製造業も、学生時代の私と同様、方法論にばかり捕らわれ、社会を豊かにするという当たり前の目的が見えなくなっているように思う。私も、ついこの間まで日本の製造業に身をおいていたのでよくわかる。もっとも、彼らが捕らわれている方法論は、経営学のそれであるようだ。
何をもって社会の豊かさとするかは難しい。今年のはじめに、ロボット掃除機のルンバを買った。まるでSFの世界にいるようだった。ハインラインの『夏への扉』に出てくる家事ロボットのようだった。私の生活は豊かになった。
今年ももう終わりだ。毎年、その年のテーマを設定することにしている。来年のテーマは「社会系」にしようと思っている。今年のうちに、古本屋行きを免れた教科書を発掘しなければならない。
『オペレーティングシステム 設計と実装 第3版』を読んだ
1953年、ワトソンとクリックによりDNAの二重らせん構造が発見されたとき、生命には神がかり的なものは何もないことが明らかとなった。以来、生命をめぐる神学上の諸々の問題は、科学とエンジニアリングの問題となった。本書を読めば、読者は、オペレーティングシステムのカーネルについて同じ発見をすることになる。
本書は、私の家の積読本コーナーにもう長いこと置かれていた。本書の原書が出版されたのが2005年。本書は、その翻訳として2007年に出版された。翻訳が出版されてすぐに手に入れたのだが、ずっと読めずにいた。何度か読もうと挑戦したものの、途中で挫折してしまっていた。読書会にも参加したが、途中で脱落してしまった。
今回、何度目かの挑戦で、ようやく読み終えることができた。実は、この本を読むのには、少々コツがあったのだ。本書は、1000ページを超える大著である上、本の後ろ半分がソースコードという、かなり特殊な本である。
本書では、カーネル、デバイスドライバ、メモリ管理、ファイルシステムのそれぞれのオペレーティングシステムのコンポーネントについて、それぞれひとつの章が割り当てられている。それぞれの章は、以下の順番で構成されている：
今まで私がどうやって読もうとしていたかというと、3と4を逐一対応付けながら読もうとしていた。つまり、ソースコードをちょっと読んで、該当する解説を読み、そしてまたソースコードに戻るという具合だ。
この読み方は、非常にしんどい。本文とソースコードとを、頻繁に行ったり来たりしなければならないからだ。すなわち、コンテキストスイッチのオーバーヘッドが大きい。
コツは、ソースコードを先に読むことだ。解説を読まずに、まず、ソースコードを読めるところまで読む。多少わからないところがあっても、本文で解説されていることを期待して、どんどん読み進む。ソースコードをある程度まとまった量（私には1ファイル分くらいが丁度よかった）読んだら、解説に目を通す。すると、自分の理解が正しかったり、あるいは間違っていたことがわかる。
本書は、Linux誕生のきっかけとなった事で有名だ。しかし、オペレーティングシステムの教科書としても非常によい本である。本書の、オペレーティングシステムのソースコードを読むことで学ぶというアプローチは、オペレーティングシステムの真の姿を明らかにする。
著者のTanenbaumは述べている：
ワトソンとクリック以来、生命は単なる有機化合物の塊となった。本書が明らかにしたように、オペレーティングシステムも、単なるCプログラムの塊に過ぎないのだ。
本書は、私の家の積読本コーナーにもう長いこと置かれていた。本書の原書が出版されたのが2005年。本書は、その翻訳として2007年に出版された。翻訳が出版されてすぐに手に入れたのだが、ずっと読めずにいた。何度か読もうと挑戦したものの、途中で挫折してしまっていた。読書会にも参加したが、途中で脱落してしまった。
今回、何度目かの挑戦で、ようやく読み終えることができた。実は、この本を読むのには、少々コツがあったのだ。本書は、1000ページを超える大著である上、本の後ろ半分がソースコードという、かなり特殊な本である。
本書では、カーネル、デバイスドライバ、メモリ管理、ファイルシステムのそれぞれのオペレーティングシステムのコンポーネントについて、それぞれひとつの章が割り当てられている。それぞれの章は、以下の順番で構成されている：
- オペレーティングシステム理論
- MINIXによる実装の概要
- MINIXのソースコード解説
- ソースコード
今まで私がどうやって読もうとしていたかというと、3と4を逐一対応付けながら読もうとしていた。つまり、ソースコードをちょっと読んで、該当する解説を読み、そしてまたソースコードに戻るという具合だ。
この読み方は、非常にしんどい。本文とソースコードとを、頻繁に行ったり来たりしなければならないからだ。すなわち、コンテキストスイッチのオーバーヘッドが大きい。
コツは、ソースコードを先に読むことだ。解説を読まずに、まず、ソースコードを読めるところまで読む。多少わからないところがあっても、本文で解説されていることを期待して、どんどん読み進む。ソースコードをある程度まとまった量（私には1ファイル分くらいが丁度よかった）読んだら、解説に目を通す。すると、自分の理解が正しかったり、あるいは間違っていたことがわかる。
本書は、Linux誕生のきっかけとなった事で有名だ。しかし、オペレーティングシステムの教科書としても非常によい本である。本書の、オペレーティングシステムのソースコードを読むことで学ぶというアプローチは、オペレーティングシステムの真の姿を明らかにする。
著者のTanenbaumは述べている：
実際のOSの真の姿は、知性的な興奮に満ちたものとは程遠く、マイナーな雑用を行うコードの集まりである。しかし、このようなコードこそシステムの可用性を向上するためには非常に重要なのである。（p.637）また、その少しあとで、こうも述べている：
優れたシステムと平凡なシステムの違いは、スケジューリングアルゴリズムのすばらしさではなく、細部まで正確に仕上げる配慮にあるのである。（p.637）私自身の学生時代を思い返してみると、オペレーティングシステムの授業では、スケジューリングやページングのアルゴリズムばかりが印象に残っている。そして、オペレーティングシステムとは、普通のプログラムとはどこか異なる、摩訶不思議な、何か神がかったものという印象を持ってしまっていた。
ワトソンとクリック以来、生命は単なる有機化合物の塊となった。本書が明らかにしたように、オペレーティングシステムも、単なるCプログラムの塊に過ぎないのだ。
