Plan9日記

■インターネットの生み出す力

年末年始にかけてNTT DoCoMoによる3Gネットワークの障害話をよく耳にしたけど、これに関連したblog「レイヤー越えが出来ない人たち」、「レイヤバイオレーション」が面白かった。システムは階層化されており、各人（組織）が得意とする階層もあるが、システムの全体最適を考えると、階層の壁を越えて考えなきゃいけないという話と、実装のことを考えると、階層を守ることはシステムの複雑さを押さえる上で重要という話。これらは完全に直交する話ではないと思うが、この手の「木を見て森を見ず」という話を聞くと、「エンド・ツー・エンドの原則とIPv6」を思い出し、また読み返してみた。言うまでもなく「End-to-end原則」はインターネットを支える設計思想である。インターネットというかARPANETの初期の頃は、TCPとIPは分離されていなかった*1。再送のようなトランスポート機能が必要かどうかはアプリに依存するので、ネットワークじゃなくて端末側に任せてしまう。このようにすることでネットワークはシンプルに保たれどんどん速くなる。システムとしての柔軟性と拡張性も得られるというわけで、インターネットは爆発的な膨張にも耐え、人々のインフラになった。End-to-end原則への言及はよく目にするが、なぜ重要なのかまで踏み込んだ文章は意外と少ないと思うので、未読な人は是非。

End-to-endというときの「end」と「end」は関係は元々は対等だったはずだが、クラウドとスマートフォンやモバイル端末という世界では、力関係が大きく異なる。そんな世界でもイノベーションは起き続けるのか？という問題提起がなされているのが、ジョナサン・ジットレインの「インターネットが死ぬ日」である*2。ジットレインは、インターネットやPCが持っていた「生み出す力」がセキュリティ強化やアプライアンス化などの「消毒」によって失われてしまうのではと危惧している。ちょっと話は脱線するが、コンピュータサイエンス（特にシステムソフトウェア）に関わる人間として、佐藤一郎氏が書いているようなクラウドのインサイダにならないと面白い研究は出来ないんじゃないの？という危惧はあるのだが（「クラウド時代の到来で、コンピュータサイエンスは「終わった」」）。閑話休題。この問題に対する一応の解決策も示しているが、それは本書を読んでもらうとして、以下ではインターネットの生み出す力について考えてみたい。

まず、生み出す力（generativity）とは、「種々雑多な幅広い人々の貢献を選別せずに受け入れることによって思いもよらない変化を実現する能力」のことだと言う。インターネットにおけるその源泉は、「問題先送りの原則」と「信頼の原則」という2大原則である。我々に馴染みのある言葉で書き直すと、前者はIETFでの標準化プロセスに関する「(We reject kings, presidents and voting. We believe in) rough consensus and running code」（デビッド・クラーク）であり、後者はプロトコルの実装に関する「Be liberal in what you accept, and conservative in what you send（人に優しく、自分に厳しく）」、いわゆる「ポスタルの法則（ロバストネス原則）」である。

「問題先送り」と聞くと言葉は悪そうに思えるが、サービスは後から付いてくるというインターネットの考えは潔い。将来のサービスがどうなるなんて予測できないのだ。従来のネットワークは電話電信にしろ、テレビにしろ、サービスありきのネットワークだった。インターネットはサービスを規定せずに始め、すべてを飲み込んでしまった。ネットワークは伝送に徹してシンプルに、末端にインテリジェントを持たせる。電話網とは正反対の考えである。TCP/IPのプロトコルレイヤの話とその上位のサービスの話がごっちゃになって整理しきれてない感じもするけど、そういう文化的背景があるということで。

（少なくともアカデミアから）インターネットの限界が叫ばれ、クリーンスレートから考え直そうという話も日米欧各国の研究者が取り組んでいるが、ぱっとした成果が出ているように見えない。そこはやっぱりいろいろ問題を抱えながらも、なんとか動いちゃっているからだろうな。いまだインターネットは新しい価値とお金を産み出し続けている。FacebookがIPO申請ということだが、その時価総額は1000億ドルとも噂されている。その一方で、ネットワーク屋は土管に徹してしまうと、どこで儲けるんだとかいうインターネットの中立性の議論もある。その背景にGoogleやAkamaiなどのHyper Giantsの登場で近年のインターネットの力関係の変化も関係しているのだろう。

あー、ぐだぐだとまとまりのない文章を書いてしまったが、今日はここまで。

Permalink | コメント(0) | トラックバック(0) | 14:19

■「割込み」の名付け親

前回、割込みの起源について触れたけど、もう少し深掘りしてみたいと思ったら、たまたま読んでいた高橋秀俊氏の伝記にPC-2の割込みの話が出てきたので、紹介しようと思う。

同氏は計算機屋からは計算機のパイオニアの一人だが、「物理の散歩道」シリーズで知られるロゲルギストの一人として記憶している人も多いだろう。計算機関係の業績としては、やはりパラメトロン計算機である。後藤英一氏の発明したパラメトロン素子を利用し、計算機PC-1、PC-2を開発した。当時の計算機屋ならば全員が読み、感銘を受けたというウィルクスの「The Preparation of Programs for an Electronic Digital Computer」を参考に、これらの計算機の命令セットはEDSACをベースに設計された。PC-1上で高橋氏が一番最初に書いたプログラムというのが「世界一周」で、先日、和田英一氏がブログにも書いておられた。これは自己書き換えを利用して、自分自身を後ろのメモリにコピーして、そこに制御を移し、動き続けるというプログラムで、メモリテストにもなったという。当然、メモリ保護機能がある、近代的な計算機、OS上でこのような行儀の悪いプログラムは動かない。しかし、自己書き換えはイニシャルオーダにも使われ、当時の計算機では欠かせないテクニックだった。

さて、このイニシャルオーダとは何だろうか。これは紙テープからプログラムを読み込み、機械語に変換し、メモリにロード、実行するプログラムで、今で言うアセンブラとローダを兼ねたものだ。OSなどに繋がる原始的なシステムソフトウェアと言える。PC-1の最初のイニシャルオーダは高橋氏が書いたが、すぐに和田氏が書いたR0に置き換えられた。R0は公開されている。私は学生時代にEDSACのイニシャルオーダを読んで感動したものだが、R0の方も読んでみたい。高橋氏曰く「芸術品」だそうだ。

EDSACやPC-1の頃の入出力と言えば紙テープやプリンタである。当時のCPUは今より圧倒的に遅かったとは言え、相対的に入出力機器が遅い状況は変わらない。入出力機器が動いている間、CPUが止まってしまうのは効率が悪い。割込み機能が欲しいというのは、このころからニーズとしてあった。EDSACにもそのような機能があったようだし、PC-2（予備テストとしてPC-1にも）にも実装された。今の計算機の割込みに近い形になったのはIBM Stretchあたりだろうか。「人月の神話」で知られるブルックスJrが1957年に「A Program-Controlled Program Interruption System」という論文を書いている。

さて、この割込みはもちろんInterruptの訳語として使われているが、もとはと言えば、高橋氏がInterruptとは独立して考え、名付けたのだそうな。いや〜、知らなかった。

割込みの歴史に関しては、Mark Smothermanの文書やHistory of Interruptsが参考になる。

Permalink | コメント(0) | トラックバック(0) | 20:38

■[失敗学] スペースシャトル用プログラミング言語HAL/S

ずいぶん間が空いてしまったけど、Make:Japanの記事に取り上げられていたスペースシャトルの制御に用いられたリアルタイムプログラミング言語HAL/Sに関する電子書籍が面白かったので、これを取り上げよう。HAL/Sは当初、宇宙機汎用言語として設計されたのだが、最終的にはスペースシャトルでしか使われることはなかった。その実態はとんでもない奴だったという話。

スペースシャトルが最初に打ち上げられたのは1981年で、昨年7月の最後のフライトでHAL/Sの役割も終わった。HAL/Sはスペースシャトルに搭載された主制御計算機AP-101用に開発されたプログラミング言語である。70年代頭という時代を考えるとアセンブリって選択肢もあったのかなと思ったけど、当時から高級言語を使いたいというニーズは明確にあったようだ。また、米国の軍事・宇宙関係のプログラミング言語だとAdaがぱっと頭に浮かぶ。Adaの国際競争入札が始まったのが1979年なので、HAL/Sの開発が始まったのはそれより前になる。言語そのものはPL/IとCOBOLのミックスみたいな言語。今日的な感性から見ると「これはちょっと」と引くけど、それを差し引けばそれほどトンデモ言語には見えない。乗算が空白という仕様を除けば。タスク間のランデブは持っているけど、セマフォなどデータの排他機構がないのもきついよな。まぁ、詳しい言語仕様はリンク先の「プログラミングHAL/S」をお楽しみあれ。

ソフトウェア障害によって重大事故が起きなかったという意味では成功かもしれないが（その開発・保守には予想を上回るコストが費やされたのは置いておいて）、後の言語に与えず忘れ去られたという意味ではコンピュータサイエンス的に失敗と言わざるを得ないだろう。HAL/Sを開発したIntermetrics社は、Ada83及びAda95規格の策定に関わり、Adaコンパイラを出荷したらしいので、HAL/Sにあったリアルタイム機能などの知見は多少反映されたのかもしれないが。この時代のリアルタイム機能というのは、タイマなどの割込みの後にいかにタスクを実行するように制御するかというと等価だったようだ。割込みはOSの誕生にも必須のハードウェア機能であり、その起源はOS屋としても興味深い（参照：Selected Historical Computer Designs）。ちなみに言語にリアルタイム機能を入れるという意味ではFORTRANを拡張したOLERT(On-Line Executive for Real-Time)が走りで、（今日的な）最初のリアルタイムOS（DEC RSX）の誕生よりも先だそうな（航天機構「極初期のリアルタイムOS」、「リアルタイムOS史追記」）。OSそのもの起源もFORTRANモニタにあったわけだし、Lispの実装もFORTRANのサブルーチンパッケージから始まった。盲腸のように蔑まれながらも、HPCなどの分野では今だしぶとく生き残るFORTRAN、侮りがたし。話がずいぶんずれてしまった。。。

スペースシャトルの制御は4台のAP-101の多数決で決まるのだけど（なんで奇数じゃない？）、ブート時にデッドロックの問題があったそうな。面白かったのでちょっと長くなるけど引用する。

問題は最初の電源投入時である。コンピュータたちは全く別々のタイミングで起動する。1981年 4 月、最初のシャトル打ち上げの予定時刻 20 分前、コンピュータに火を入れるはずが全然起動しなかった。4 台のコンピュータが順番に互いにバスを閉じ合って、同期に失敗するデッドロックに陥ったのである。症状は即座にデッドロックだと診断された。打ち上げは 2 日延ばされ、ソフトウェアはそのままに打ち上げられた。

後の解析によると、電源投入は 67 分の 1 の確率でデッドロックにより失敗する事が判明した。初期化コードの肥大化によって起動に要する時間が延びて、初期の設計に無いデッドロックタイミングが生じたと診断された。調査すると、デッドロックは三ヶ月前にも一度開発中に起きていた。その後もバグは発覚し続けたが、ソフトウェアの修正により新しいリスクを抱え込むより、テスト済みであるプログラムをそのまま使い続ける方針が維持された。バグは発見され次第、それを避ける詳細な手順書が作成された。STS-7 ミッションの時には、それは既に 200 ページにも渡っていた。バグの実際の修正はチャレンジャー事故後に一括して行われた。

余談になるが、この電子書籍の筆者の水城徹さんのblog「航天機構 lifelog」が面白い。宇宙開発に興味がある人以外にも、組み込みシステムなどIT系の人間にも楽しめる話題がいろいろでお勧め。ソユーズに搭載されたTsVM-101にはMIPS互換CPUが載っているというのは初耳。そう言えば、放射線の影響というと、光ファイバーは放射線を浴びると白濁してしまうので、宇宙では使えないそうな。

アポロの月面ミッションを支えた誘導コンピュータAGCに関しては次の書に詳しい。AGCのソフトウェアはアセンブリで開発された。

（追記：2012-01-24）Virtual AGCとか熱いなぁ。

Permalink | コメント(1) | トラックバック(1) | 11:37

■ ちょっと普通じゃないTremaの動かし方

第2回クラウドネットワーク研究会「OpenFlow祭」でも好評だったOpenFlowコントローラフレームワークTrema。TremaをVMWare FusionのLinux上で動かしてみたときのメモを残しておこう。OpenFlowとPlan 9の関係は？と聞かれたけど、これには触れないことにしておくw

TremaはOpen vSwitchを使った仮想ネットワーク構築機能を持っているので、OpenFlowに興味はあるけど、OpenFlowスイッチを持っていない人でも気軽に動かして試すことができる。ここではVMWareのhgfs上でTremaを動かす方法を書く。TremaはトップディレクトリのtmpディレクトリにUNIXドメインソケットを張るんだけど、hgfs側が対応していないので、そのままでは動かない。tmpディレクトリを/tmpなどに切り替える必要がある。ぱっと見、環境変数TREMA_TMPってのがあるし、対応済みみたいなんだけど、Open vSwitchとの通信で抜けがあるようなので、以下のパッチを適用する。

• https://gist.github.com/1234219

まず、build時にTREMA_TMPを指定する。

$ git clone git://github.com/trema/trema
$ cd trema
$ TREMA_TMP=/tmp ./build.rb

実行するときもTREMA_TMPを指定する。

$ TREMA_TMP=/tmp ./trema run hello_trema.rb
Hello, Trema!
^C

こんな動かし方する人はいないんじゃないかという気がするけどね。。。

そもそも、TremaというかOpen vSwitchがMac OS X上で動くようになるとこんなことしなくてもよいのに。

Permalink | コメント(0) | トラックバック(0) | 11:40

■[UNIX V6] FUSEでUNIX V6ファイルシステムをマウント

Lions本合宿のネタに、ユーザ空間でファイルシステムを作ることが出来るMacFUSEを使って、UNIX V6ファイルシステムをマウントできないかと考えていた。@7shiさんや@superhogeさんとは別アプローチとして。

さっそくMacFUSEのソースコードをダウンロードし、まずはhellofsかなと試す。でも、

$ make hello
$ mkdir /Volumes/hello
$ ./hello /Volumes/hello
$ ls /Volumes/hello
ls: /Volumes/hello: Input/output error

とか言われて動かないし。。。で、他のサンプルはないものかとディレクトリを眺めていると、AncientFSなるものを見つけてしまった。まさに自分がやろうと思っていたことだった。しかも、V6だけではなく、V1のDECtapeから2.11 BSDのファイルシステムまでいろんなフォーマットに対応している。かなりマニアックだなぁ。

使い方は簡単。simhなどで使っているイメージファイルをv6rootとすると。おぉ、ちゃんと読めてる。

$ mkdir /Volumes/v6root
$ ancientfs --type v6 --dmg v6root /Volumes/v6root
$ ls -als /Volumes/v6root
total 241
 1 drwxrwxr-x   9 3     sys      256 Jul 19  1975 .
 0 drwxrwxrwt@  4 root  admin    170 Sep 23 07:18 ..
 3 drwxrwxr-x   2 3     sys     1104 Oct 11  1975 bin
 4 drwxrwxr-x   2 3     sys     1824 Oct 11  1975 dev
 1 drwxrwxr-x   2 3     sys      496 Oct 11  1975 etc
57 -rwxrwxrwx   1 root  sys    29074 Oct 11  1975 hpunix
 1 drwxrwxr-x   2 3     sys      464 May 14  1975 lib
 1 drwxrwxr-x   2 3     sys       32 May 14  1975 mnt
57 -rwxrwxrwx   1 root  sys    28836 Oct 11  1975 rkunix
57 -rwxrwxrwx   1 root  sys    29020 Oct 11  1975 rpunix
 1 drwxrwxrwx   2 3     sys      368 Oct 11  1975 tmp
57 -rw-rw-rw-   1 root  sys    28836 Oct 11  1975 unix
 1 drwxrwxr-x  17 3     sys      272 Oct 11  1975 usr

このファイルシステムはread onlyなので、書き込みに対応するという方向性はあるかな。

Permalink | コメント(0) | トラックバック(0) | 07:29