三菱を去る日
1月いっぱいで三菱電機を退職した。新卒で入社してから、この４月で丸６年になるところだった。実は、退職にあたってのエントリを、同じタイトルで前々から用意していた。三菱の官僚主義に辟易していた私は、三菱のやり方について、そのエントリでこき下ろす予定だった。だが、気が変わった。
最後の出勤が終わったあと、6年間住んだ独身寮へ行った。部屋の鍵を返すためだ。まだ部屋に置いたままになっていたゴミを処分し、掃除機をかけた。そして、鍵を返すために管理人室へ行った。管理人さんは、なぜかいつも私をフルネームで呼ぶ。私は鍵を返し、簡単にお礼を述べた。管理人さんも何か言った。
瞬間、私は、目から涙が出そうになっていることに気づいた。私は慌てて管理人室をあとにし、駅へと向かった。管理人さんが何を言ったのか、正確には覚えていない。しかし、励ましの言葉だったのは確かだ。
管理人さんのその言葉は、私の頭脳で解釈される前に、私の心の中の大きく膨らんだ風船を突き刺してしまった。風船は弾け、中の物が溢れ出し、私はうかつにも涙を浮かべてしまった。風船の中身は何だったのか？
退職当日というのは意外と忙しい。あれやこれやの手続きに、机周りの整理。それが終わったら、お世話になった人への挨拶だ。しかし、上に書いたように、私は三菱が嫌で辞めるのであるから、特に誰かに挨拶して回ろうとは思っていなかった。親しい友人には事前に退職を知らせてあったし、同期入社の仲間たちにはメールで知らせた。手続きや机の整理は午前中でほとんど終わってしまったので、午後は缶ジュースなど飲みつつのんびり過ごした。
定時になって、課の人たちの前で挨拶をした。挨拶が終われば帰っていいわけだが、持ち帰らなければならない荷物が多かったので、フロアの友人にあげてしまおうと思った。形見分けというわけだ。そこで、私は「形見」を持ってフロアを歩きまわった。
フロアを見渡すと、色々な人たちの顔があった。私は、その中の実に多くの人と、この6年の間に一緒に仕事をしてきたことに気づいた。一緒にデスマーチを乗り越えた人もいたし、一緒にお酒を飲んだことがあるだけの人もいた。挨拶回りなどしないと決めていたはずなのに、私は彼らに声をかけた。彼らは気持よく送り出してくれた。
私の三菱電機での6年間は、常に不幸だった。デスマーチも経験したし、体調を崩したこともあった。そもそも、担当する仕事が退屈極まりなかった。しかし、ひとつだけ素晴らしいことに、私がどんなに苦しい時でも、私のそばには常に誰かがついていてくれた。私はひとりで置いておかれることはなかった。疎外されることもなかった。
これが風船の中身だった。駅へと向かう道で、このことに気づいた。私は、薄暗い路地へ駆け込み、静かに涙を流した。私は、再び駅へと歩き出した。途中のコンビニでコーヒーを買おうと思った。寮の近くの、馴染みのコンビニだった。コンビニの外に、大きな黒い犬がつながれていた。飼い主は買い物中なのだろう。私は、その犬の頭を撫で、ようやく落ち着きを取り戻した。
私は三菱の官僚主義を嫌った。これを書いている今も嫌いだし、そういうやり方は私には合わないと思う。しかし、私が見逃していたことに、その官僚主義の中にいる人々は皆善人だった。もしかすると、彼らも官僚主義を嫌っているかも知れない。さらに、官僚主義と日々戦っているのかも知れない。
彼らは残り、私は去った。何だか、私だけがさっさと逃げ出してしまったような気もする。退職を後悔しているわけではない。だが、すごく不思議な気持ちだ。彼らのためにも、というのは変な表現だが、次の職場ではがんばろうと思う。
ありがとう、三菱電機。この6年間は本当は幸せだったのだ。素晴らしい人達と過ごせたのだから。
最後の出勤が終わったあと、6年間住んだ独身寮へ行った。部屋の鍵を返すためだ。まだ部屋に置いたままになっていたゴミを処分し、掃除機をかけた。そして、鍵を返すために管理人室へ行った。管理人さんは、なぜかいつも私をフルネームで呼ぶ。私は鍵を返し、簡単にお礼を述べた。管理人さんも何か言った。
瞬間、私は、目から涙が出そうになっていることに気づいた。私は慌てて管理人室をあとにし、駅へと向かった。管理人さんが何を言ったのか、正確には覚えていない。しかし、励ましの言葉だったのは確かだ。
管理人さんのその言葉は、私の頭脳で解釈される前に、私の心の中の大きく膨らんだ風船を突き刺してしまった。風船は弾け、中の物が溢れ出し、私はうかつにも涙を浮かべてしまった。風船の中身は何だったのか？
退職当日というのは意外と忙しい。あれやこれやの手続きに、机周りの整理。それが終わったら、お世話になった人への挨拶だ。しかし、上に書いたように、私は三菱が嫌で辞めるのであるから、特に誰かに挨拶して回ろうとは思っていなかった。親しい友人には事前に退職を知らせてあったし、同期入社の仲間たちにはメールで知らせた。手続きや机の整理は午前中でほとんど終わってしまったので、午後は缶ジュースなど飲みつつのんびり過ごした。
定時になって、課の人たちの前で挨拶をした。挨拶が終われば帰っていいわけだが、持ち帰らなければならない荷物が多かったので、フロアの友人にあげてしまおうと思った。形見分けというわけだ。そこで、私は「形見」を持ってフロアを歩きまわった。
フロアを見渡すと、色々な人たちの顔があった。私は、その中の実に多くの人と、この6年の間に一緒に仕事をしてきたことに気づいた。一緒にデスマーチを乗り越えた人もいたし、一緒にお酒を飲んだことがあるだけの人もいた。挨拶回りなどしないと決めていたはずなのに、私は彼らに声をかけた。彼らは気持よく送り出してくれた。
私の三菱電機での6年間は、常に不幸だった。デスマーチも経験したし、体調を崩したこともあった。そもそも、担当する仕事が退屈極まりなかった。しかし、ひとつだけ素晴らしいことに、私がどんなに苦しい時でも、私のそばには常に誰かがついていてくれた。私はひとりで置いておかれることはなかった。疎外されることもなかった。
これが風船の中身だった。駅へと向かう道で、このことに気づいた。私は、薄暗い路地へ駆け込み、静かに涙を流した。私は、再び駅へと歩き出した。途中のコンビニでコーヒーを買おうと思った。寮の近くの、馴染みのコンビニだった。コンビニの外に、大きな黒い犬がつながれていた。飼い主は買い物中なのだろう。私は、その犬の頭を撫で、ようやく落ち着きを取り戻した。
私は三菱の官僚主義を嫌った。これを書いている今も嫌いだし、そういうやり方は私には合わないと思う。しかし、私が見逃していたことに、その官僚主義の中にいる人々は皆善人だった。もしかすると、彼らも官僚主義を嫌っているかも知れない。さらに、官僚主義と日々戦っているのかも知れない。
彼らは残り、私は去った。何だか、私だけがさっさと逃げ出してしまったような気もする。退職を後悔しているわけではない。だが、すごく不思議な気持ちだ。彼らのためにも、というのは変な表現だが、次の職場ではがんばろうと思う。
ありがとう、三菱電機。この6年間は本当は幸せだったのだ。素晴らしい人達と過ごせたのだから。
『一般意志2.0』を読んだ
今年の正月休みも実家へ帰っていた。１日だけ地元の友人たちと会い、あとは本を何冊か読んで過ごした。その中に、東浩紀さんの『一般意志2.0』というのがあった。帰省前に、藤沢のジュンク堂で見かけ、Twitterで話題になっているのを思い出して購入したものだ。
この本は、GoogleやTwitterといった現代のWebテクノロジーを、ルソーやフロイトなどの過去の思想家の視点から解釈してみせる。これは、Webテクノロジーを、社会的・政治的・人間的側面から眺めてみることである。
私はプログラマだ。だから、どうしても技術的な側面ばかりに注目してしまう。もちろん、社会的側面があることはわかっている。しかし、具体的に社会にどう影響を与えたか、あるいは今後与えうるかと問われると、答えに窮してしまう。せいぜい、「１０年前、２０年前とはずいぶんと違った世の中になったな」としか答えられない。
この本は、ひとつのヴィジョンである。アラン・ケイのダイナブック、スティーブ・ジョブズの美しいコンピュータと同じだ。あるいは、６０年前の人が空想した、原子力で動く自動車だ。未来は、この本のとおりになるかもしれないし、ならないかもしれない（多分ならない。ヴィジョンの平均値は「実現しない」である）。それでも、この本は我々の想像力を大いに喚起する。
この『一般意志2.0』だが、Amazonでのレビューは、星１つから星５つまで評価が割れている。こういう本は議論を呼ぶ。議論を呼ぶ本は面白い。私も、大いに楽しんだ。
だから、このエントリを読んでいてまだ本書を読んでいない人は、ぜひ読んでみてほしい。あなたは大いに感銘を受けるかもしれないし、東浩紀は何という大ばか者だと思うかもしれない。しかし、何も印象に残らないということはないはずだ。
この本は、GoogleやTwitterといった現代のWebテクノロジーを、ルソーやフロイトなどの過去の思想家の視点から解釈してみせる。これは、Webテクノロジーを、社会的・政治的・人間的側面から眺めてみることである。
私はプログラマだ。だから、どうしても技術的な側面ばかりに注目してしまう。もちろん、社会的側面があることはわかっている。しかし、具体的に社会にどう影響を与えたか、あるいは今後与えうるかと問われると、答えに窮してしまう。せいぜい、「１０年前、２０年前とはずいぶんと違った世の中になったな」としか答えられない。
この本は、ひとつのヴィジョンである。アラン・ケイのダイナブック、スティーブ・ジョブズの美しいコンピュータと同じだ。あるいは、６０年前の人が空想した、原子力で動く自動車だ。未来は、この本のとおりになるかもしれないし、ならないかもしれない（多分ならない。ヴィジョンの平均値は「実現しない」である）。それでも、この本は我々の想像力を大いに喚起する。
この『一般意志2.0』だが、Amazonでのレビューは、星１つから星５つまで評価が割れている。こういう本は議論を呼ぶ。議論を呼ぶ本は面白い。私も、大いに楽しんだ。
だから、このエントリを読んでいてまだ本書を読んでいない人は、ぜひ読んでみてほしい。あなたは大いに感銘を受けるかもしれないし、東浩紀は何という大ばか者だと思うかもしれない。しかし、何も印象に残らないということはないはずだ。
ハッカーセントリックな企業文化
TechLION vol.5に行ってきた：
http://www.usptomonokai.jp/wp/?p=2068
自称プロの酔っぱらいである楽天のよしおかさんが、「ハッカーセントリックな企業文化」について語るということだった。Twitterを見ていると、すでに楽屋でビールを飲んでおられたようだった。さすがプロである。
よしおかさんはこう言う：
では、ハッカー的モノづくりと、非ハッカー的モノづくりを隔てるものは何だろうか？ どうして、ハッカーのほうが素晴らしいモノづくりができるのだろうか？ これは、ハッカーと非ハッカーがモノづくりに対してとる態度の違いに現れているように思う。
モノづくりにおいて、リスクを回避する最も簡単な方法は、モノを作らないことだ。もちろん、モノがなければシステムは作れないので、実際にはコンポーネントを買ってくることになる。これは、実際に私の現場でも行われていて、COTS(Commercial Off The Shelf)というカッコイイ名前で呼ばれている。
COTSを利用するメリットは、そのコンポーネントに関するあらゆるリスクをベンダーに転嫁できる（と非ハッカーは考える）ことだ。COTSのバグが見つかったら、ベンダーへ怒りの電話を入れればよい。彼らが徹夜で直してくれるはずだ（と非ハッカーは考える）。
ハッカーは、既存のコンポーネントを組み合わせてシステムを作る事自体には反対しない。むしろ、そのようなモノづくりは「巨人の方に乗る」ものとして賞賛されさえする。実際、ハッカーはオープンソースのコンポーネントをよく利用する。問題は、そのコンポーネントに対する「態度」だ。
例えば、あるコンポーネントでバグが見つかったときに、「そのコンポーネントはCOTSなので私には関係ありません」と言って責任逃れをするのは非ハッカー的態度だ。このような言い訳はハッカーとしてのプライドを大きく傷つけるものだし、こういう言い訳をする人間はハッカーではないと他のハッカーから見なされる。
ハッカーがオープンソースを好む理由もここにある。ソースがあって自分でいじくり回すことができるからこそ、すべての責任を取ることができる。すべてをコントロールすることができる。責任逃れはできないのだ。
ここからわかることは、ハッカーは自分の作った製品やサービスに対して非常に責任感が強いということだ。これは、ハッカーの一見自由奔放なイメージとはかなり違う。実は、非ハッカーのほうが責任感がない。非ハッカーは、いかにして責任を取らずに済むかを考える。
だから、もし本当に素晴らしいモノづくりがしたいのなら、ハッカーの態度を真似るべきだ。次に何か責任逃れをしようと思うときがあったら、グッとこらえて「自分の責任」にしてしまおう。自分でデバッグに乗り出そう。そして、いつでもそうできるようにオープンソースを採用しよう。
でも、どうしてもハッカーセントリックな企業文化が自分の会社に根付かないのなら、他のハッカーを探して別の会社に移るというのも手かもしれない。世の中には、ハッカーはたくさんいるはずだ。
http://www.usptomonokai.jp/wp/?p=2068
自称プロの酔っぱらいである楽天のよしおかさんが、「ハッカーセントリックな企業文化」について語るということだった。Twitterを見ていると、すでに楽屋でビールを飲んでおられたようだった。さすがプロである。
よしおかさんはこう言う：
良いソフトウェア、良いシステムを作りたいなら、最高のプログラマを雇うべき。見も蓋もない話なんですよ。ここで言う「最高のプログラマ」というのが、ハッカーということなのだろう。
では、ハッカー的モノづくりと、非ハッカー的モノづくりを隔てるものは何だろうか？ どうして、ハッカーのほうが素晴らしいモノづくりができるのだろうか？ これは、ハッカーと非ハッカーがモノづくりに対してとる態度の違いに現れているように思う。
モノづくりにおいて、リスクを回避する最も簡単な方法は、モノを作らないことだ。もちろん、モノがなければシステムは作れないので、実際にはコンポーネントを買ってくることになる。これは、実際に私の現場でも行われていて、COTS(Commercial Off The Shelf)というカッコイイ名前で呼ばれている。
COTSを利用するメリットは、そのコンポーネントに関するあらゆるリスクをベンダーに転嫁できる（と非ハッカーは考える）ことだ。COTSのバグが見つかったら、ベンダーへ怒りの電話を入れればよい。彼らが徹夜で直してくれるはずだ（と非ハッカーは考える）。
ハッカーは、既存のコンポーネントを組み合わせてシステムを作る事自体には反対しない。むしろ、そのようなモノづくりは「巨人の方に乗る」ものとして賞賛されさえする。実際、ハッカーはオープンソースのコンポーネントをよく利用する。問題は、そのコンポーネントに対する「態度」だ。
例えば、あるコンポーネントでバグが見つかったときに、「そのコンポーネントはCOTSなので私には関係ありません」と言って責任逃れをするのは非ハッカー的態度だ。このような言い訳はハッカーとしてのプライドを大きく傷つけるものだし、こういう言い訳をする人間はハッカーではないと他のハッカーから見なされる。
ハッカーがオープンソースを好む理由もここにある。ソースがあって自分でいじくり回すことができるからこそ、すべての責任を取ることができる。すべてをコントロールすることができる。責任逃れはできないのだ。
ここからわかることは、ハッカーは自分の作った製品やサービスに対して非常に責任感が強いということだ。これは、ハッカーの一見自由奔放なイメージとはかなり違う。実は、非ハッカーのほうが責任感がない。非ハッカーは、いかにして責任を取らずに済むかを考える。
だから、もし本当に素晴らしいモノづくりがしたいのなら、ハッカーの態度を真似るべきだ。次に何か責任逃れをしようと思うときがあったら、グッとこらえて「自分の責任」にしてしまおう。自分でデバッグに乗り出そう。そして、いつでもそうできるようにオープンソースを採用しよう。
でも、どうしてもハッカーセントリックな企業文化が自分の会社に根付かないのなら、他のハッカーを探して別の会社に移るというのも手かもしれない。世の中には、ハッカーはたくさんいるはずだ。
xv6を読む：メモリアロケータ
実行時に、プロセスやカーネルにページを割り当てるため、xv6はメモリアロケータを使用する。メモリアロケータは、未使用のページのフリーリストを管理している。カーネルからの要求に従って、フリーリストからページを割り当てる。
カーネルの起動処理で、フリーリストを未使用のページで満たさなければならない。ここで、鶏と卵の問題が生じる。すなわち、フリーリストの初期化処理を行うためにはカーネルに物理メモリが割り当てられていなければならず、カーネルに物理メモリを割り当てるためにはメモリアロケータが動作しなければならない。
xv6では、フリーリストの初期化を二段階で行うことで、これを解決している。main関数から呼び出されるkinit1関数と、kinit2関数がそれである。関数呼び出しの関係を以下に示す：
main
:
+->kinit1
| +->initlock
| +->freerange
| +->kfree
+->kvmalloc（前回説明。kinit1で初期化したページを使用する）
:
+->kinit2
| +->freerange
| +->kfree
:
ここで、xv6のアドレス空間について少し説明する。仮想アドレス空間を左に、物理アドレス空間を右に示す：
4G->+----+
/| |\
Device | |
\| |
0xFE000000->|----|
/| |
| |
Free Memory | | Kernel Space
| |
\| |
end->| | +----+<-4G
| | | |\
+0x100000->| | | | Device
KERNBASE->| | | |/
/|----|/ |----|<-PHYSTOP
| | | |\
| | | |
| | | |
| | | | Extended Memory
| | | |
User Space | | | |
| | | |
| | |----|/
| | | |<-0x100000
| | | |<-I/O Space
| | | |<-640k
\| | | |<-Base Memory
0->+----+ +----+
Vertual Physical
仮想アドレス空間では、カーネルは上位2GBにマップされる（KERNBASE=2GBに定義されている）。したがって、ユーザプロセスは2GBまでのアドレス空間を利用できる。カーネルのテキストとデータは、仮想アドレスでKERNBASE + 0x100000〜endの間にロードされる。これは、物理アドレス0x100000〜end - KERNBASEにマップされている。
物理アドレス空間で、カーネルの後ろ、すなわちend - KERNBASEからPHYSTOPまでの空間をページとして利用する。メモリアロケータは、この部分をフリーリストとして管理する。PHYSTOPは240MBに定義されている。
xv6はブート時のページテーブルとして、entrypgdirを持っている。entrypgdirは、仮想アドレスの0〜4MBを実アドレスの0〜4MBへ、仮想アドレスのKERNBASE〜KERNBASE + 4MBを実アドレスの0〜4MBへマップするよう設定されている。前回説明したkvmallocでカーネルページテーブルが作成されるまでは、カーネルはこのページテーブルを用いてアドレス変換を行う。すなわち、xv6は、カーネルのサイズは少なくとも4MBより小さいものと仮定している。
さて、kinit1では、end〜4MBまでの物理アドレス空間を4KBのページに分割し、フリーリストに登録する。この処理を行うのが、freerange関数とkfree関数である。kinit1は、main関数内で以下のように呼び出されている：
kinit1(end, P2V(4*1024*1024));
ここで、P2Vマクロは物理アドレスを仮想アドレスに変換するマクロである。このマクロは、単に引数 + KERNBASEに展開されるだけである。
freerange関数は、以下の処理を行う：
以上で、フリーリストの初期化の第1段階が完了した。これで、4MBまでの範囲で、メモリアロケータはページを割り当てることができる。
フリーリストの初期化の第2段階であるkinit2関数は、main関数のかなり後のほうで、以下のように呼び出されている：
kinit2(P2V(4*1024*1024), P2V(PHYSTOP));
4MBからPHYSTOPまでの物理アドレス空間を、フリーリストに登録する。以上でフリーリストの初期化はすべて完了し、メモリアロケータを使用することができる。
カーネルの起動処理で、フリーリストを未使用のページで満たさなければならない。ここで、鶏と卵の問題が生じる。すなわち、フリーリストの初期化処理を行うためにはカーネルに物理メモリが割り当てられていなければならず、カーネルに物理メモリを割り当てるためにはメモリアロケータが動作しなければならない。
xv6では、フリーリストの初期化を二段階で行うことで、これを解決している。main関数から呼び出されるkinit1関数と、kinit2関数がそれである。関数呼び出しの関係を以下に示す：
main
:
+->kinit1
| +->initlock
| +->freerange
| +->kfree
+->kvmalloc（前回説明。kinit1で初期化したページを使用する）
:
+->kinit2
| +->freerange
| +->kfree
:
ここで、xv6のアドレス空間について少し説明する。仮想アドレス空間を左に、物理アドレス空間を右に示す：
4G->+----+
/| |\
Device | |
\| |
0xFE000000->|----|
/| |
| |
Free Memory | | Kernel Space
| |
\| |
end->| | +----+<-4G
| | | |\
+0x100000->| | | | Device
KERNBASE->| | | |/
/|----|/ |----|<-PHYSTOP
| | | |\
| | | |
| | | |
| | | | Extended Memory
| | | |
User Space | | | |
| | | |
| | |----|/
| | | |<-0x100000
| | | |<-I/O Space
| | | |<-640k
\| | | |<-Base Memory
0->+----+ +----+
Vertual Physical
仮想アドレス空間では、カーネルは上位2GBにマップされる（KERNBASE=2GBに定義されている）。したがって、ユーザプロセスは2GBまでのアドレス空間を利用できる。カーネルのテキストとデータは、仮想アドレスでKERNBASE + 0x100000〜endの間にロードされる。これは、物理アドレス0x100000〜end - KERNBASEにマップされている。
物理アドレス空間で、カーネルの後ろ、すなわちend - KERNBASEからPHYSTOPまでの空間をページとして利用する。メモリアロケータは、この部分をフリーリストとして管理する。PHYSTOPは240MBに定義されている。
xv6はブート時のページテーブルとして、entrypgdirを持っている。entrypgdirは、仮想アドレスの0〜4MBを実アドレスの0〜4MBへ、仮想アドレスのKERNBASE〜KERNBASE + 4MBを実アドレスの0〜4MBへマップするよう設定されている。前回説明したkvmallocでカーネルページテーブルが作成されるまでは、カーネルはこのページテーブルを用いてアドレス変換を行う。すなわち、xv6は、カーネルのサイズは少なくとも4MBより小さいものと仮定している。
さて、kinit1では、end〜4MBまでの物理アドレス空間を4KBのページに分割し、フリーリストに登録する。この処理を行うのが、freerange関数とkfree関数である。kinit1は、main関数内で以下のように呼び出されている：
kinit1(end, P2V(4*1024*1024));
ここで、P2Vマクロは物理アドレスを仮想アドレスに変換するマクロである。このマクロは、単に引数 + KERNBASEに展開されるだけである。
freerange関数は、以下の処理を行う：
- 引数vstartとvendで渡された仮想アドレス空間（範囲）についてPGSIZE(4KB)ごとにkfree関数を呼び出す
- 引数vで渡された仮想アドレスが以下の条件にない場合、パニックする：
- ページ境界に合っていない
- endより小さい
- v2p(v)がPHYSTOP以上である
- vから1ページ分、メモリ領域を1で埋める
- vをフリーリストにつなぐ
以上で、フリーリストの初期化の第1段階が完了した。これで、4MBまでの範囲で、メモリアロケータはページを割り当てることができる。
フリーリストの初期化の第2段階であるkinit2関数は、main関数のかなり後のほうで、以下のように呼び出されている：
kinit2(P2V(4*1024*1024), P2V(PHYSTOP));
4MBからPHYSTOPまでの物理アドレス空間を、フリーリストに登録する。以上でフリーリストの初期化はすべて完了し、メモリアロケータを使用することができる。
xv6を読む：アドレススペースの作成
xv6というOSがある。これは、UNIX V6をベースに（？）MITで開発された教育用のOSである。x86アーキテクチャで動作する。MITなどのアメリカの大学が凄いと思うのは、授業の教材や講義の録画をネットで公開してしまうことである。xv6もテキストとソースコードが公開されている：
http://pdos.csail.mit.edu/6.828/2011/xv6.html
xv6のテキストは、解説とソースコードがLions' Commentaryのように2分冊になっている。それぞれ100ページ以下である。テキストを読み進めてみると、xv6は、x86アーキテクチャとその応用であるOSを勉強するのに格好の教材になりそうだ。
そこで、勉強の成果を忘れないようにメモしておくため、そして、もしかしたら私のメモが役に立つという人もいるかもしれないので、このブログでまとめていくことにする。もちろん、ツッコミは大歓迎である。今回は、アドレススペースの作成である。
OSのブート後、main関数が呼ばれる。最初に、main関数では、アドレススペースの作成が行われる。ここでは、仮想アドレスから物理アドレスへマップするページテーブルを作成する。x86での仮想アドレスは3つの部分を持つ。以下に、mmu.hから引用する：
main
:
+->kvmalloc
| +->setupkvm
| | +->mappages
| | +->walkpgdir
| +->switchkvm
:
setupkvm関数では次の処理を行う：
mappages関数は次の処理を行う：
http://pdos.csail.mit.edu/6.828/2011/xv6.html
xv6のテキストは、解説とソースコードがLions' Commentaryのように2分冊になっている。それぞれ100ページ以下である。テキストを読み進めてみると、xv6は、x86アーキテクチャとその応用であるOSを勉強するのに格好の教材になりそうだ。
そこで、勉強の成果を忘れないようにメモしておくため、そして、もしかしたら私のメモが役に立つという人もいるかもしれないので、このブログでまとめていくことにする。もちろん、ツッコミは大歓迎である。今回は、アドレススペースの作成である。
OSのブート後、main関数が呼ばれる。最初に、main関数では、アドレススペースの作成が行われる。ここでは、仮想アドレスから物理アドレスへマップするページテーブルを作成する。x86での仮想アドレスは3つの部分を持つ。以下に、mmu.hから引用する：
+--------10------+-------10-------+---------12----------+
| Page Directory | Page Table | Offset within Page |
| Index | Index | |
+----------------+----------------+---------------------+
\--- PDX(va) --/ \--- PTX(va) --/
仮想アドレスは、それぞれ10ビットのページディレクトリインデックスとページテーブルインデックス、そして12ビットのページ内オフセットからなる。それぞれの意味を以下に示す：
アドレススペースの作成は、main関数からのkvmalloc関数の呼び出しで行う。setupkvm関数でページディレクトリを作成し、それをswitchkvm関数でCR3レジスタに設定する。関数の呼び出し関係を以下に示す：
main
:
+->kvmalloc
| +->setupkvm
| | +->mappages
| | +->walkpgdir
| +->switchkvm
:
setupkvm関数では次の処理を行う：
- ページディレクトリ用に1ページ（4KB）を割り当てる
- 次の各カーネル領域について、mappages関数を呼び出すことで、ページテーブルを作成し、ページディレクトリエントリに書きこむ：
- 作成したページテーブルを、1のページディレクトリに書き込み、返す
ここで、各カーネル領域は任意の大きさでよい。mappages関数に領域のサイズを渡すことで、必要な分だけページテーブルが割り当てられる。
- walkpgdir関数を呼び出し、引数で渡された仮想アドレスに対応する、ページテーブルエントリを取得する
- エントリにマップする物理アドレス、アクセス権、存在ビットを書きこむ
- 領域全体をマップし終わるまで1から繰り返す
walkpgdir関数は次の処理を行う：
- ページディレクトリから、ページディレクトリインデックスに該当するエントリを引く
- 1で引いたエントリの存在フラグが立っていれば、ページテーブルを取得する（エントリに記述されているアドレスに存在するはず）
- 2でない場合、関数の引数でallocフラグに真が渡された場合（この場合はそうである）、新たに1ページ取得し、これをページテーブルとする。このページテーブルの物理アドレス、存在ビット、書き込み可ビット、ユーザ空間ビットを、1で取得したエントリに書きこむ
- 2または3で取得したページテーブルから、ページテーブルインデックスに該当するエントリのアドレスを返す
以上で、アドレススペースを作成した。ただし、ここで作成したのはページテーブルまでで、物理ページの割り当ては行っていない。次回は、テキストに従って、物理メモリの割り当てに進みたい。
スキルかセンスか？
ちょっと前の話になるのだが、「デザイナ＆エンジニア交流会」というのに参加してきた：
http://design1.chu.jp/setucocms-pjt/?p=1770
SetsucoCMSというオープンソースのCMSがあって、それを作っている子たちによく遊んでもらっている。今回、彼らが勉強会をやるということで、私も誘われた。デザイナやエンジニアと言っても、ここでは「Web」デザイナ、「Web」エンジニアである。Webにとんと疎い私としては、そこはまったくの異文化圏である。そこでの交流は、なかなか刺激的であった。
中でも非常に新鮮だったは、普段接することのないデザイナと話す機会を持てたことだ。そして、彼らと話してわかったことには、どうやら彼らは、デザインがセンスだとエンジニアに思われていることに強い不満を持っているらしい。
確かに、「デザイン」というと、何だか芸術的なものを連想してしまう。実際、私もデザインはセンス、つまり才能によるところが大きいのだろうと何となく思っていた。しかし、デザイナの彼らに言わせれば、デザインには理論があり、練習によって習得できるものであって、したがってデザインはスキルであるという。
ここでちょっと野球を考えてみる。長嶋茂雄さんといえば往年のスター選手だ。あるとき、ホームランの打ち方を聞かれた長嶋さんは、「ボールが来たら、よく見て打て」と大真面目に答えたそうだ。長嶋さんにとっては、それがホームランの理論であり、練習によって習得したということだろう。
デザイナが、デザインがセンスだというエンジニアの思い込みに不満を持つということは、その裏返しとして、彼らは、エンジニアリングはスキルだと思っているのかもしれない。しかし、この思い込みが必ずしも正しくないことは、プログラマなら誰もが知っている。
確かに、プログラミングには理論が存在する。ソフトウェア工学と呼ばれているものがそれだ。プログラミングの外にいる人の目には、プログラミングとはソフトウェア工学の実践であって、練習によって習得できるものと映るかもしれない。しかし、そうだとしたら、どうしてこんなにも多くのソフトウェア開発プロジェクトが失敗するのだろう？ プログラマはみんなあまりにも怠惰過ぎて、練習を怠っているということだろうか？
私が思うに、プログラミングは野球みたいなものだ。ソフトウェア工学は長嶋さんのホームラン理論に似ている。この理論は間違ってはいないが、本当にホームランを打とうとするなら、理論以外の何かが必要だ。そして、重要なことは、あの長嶋さんでさえ、毎回ホームランを打てたわけではないということだ。
交流会の後の懇親会で、私はデザイナの一人に、「エンジニアリングはスキルですか？」と聞かれた。私は、「ある部分はスキルでしょう。しかし、センスが必要な部分もたくさんありますよ」と答えた。この時は酔っ払っていたのでうまく説明できなかったが、私が言いたかったのは、つまるところエンジニアリングとはホームラン理論だということだ。
だから、デザイナは、自分たちがやっていることがスキルかセンスかなんて悩む必要はないと思う。たぶん、デザインもホームラン理論だ。部外者から見るとセンスに見えるかもしれないが、実際にはスキルとセンスの混合物なのだろう。
最後に、今回の交流会を主催し、そして私を呼んでくれたSetsucoCMSのみんなにお礼を言おう。彼らはとても若く、パワフルで、情熱に溢れている。そして何より、彼らはものづくりに対してとても真面目である。彼らの今後の活躍には私は大きく期待するし、また、今後もこういった交流会に呼んでほしいと思う。
http://design1.chu.jp/setucocms-pjt/?p=1770
SetsucoCMSというオープンソースのCMSがあって、それを作っている子たちによく遊んでもらっている。今回、彼らが勉強会をやるということで、私も誘われた。デザイナやエンジニアと言っても、ここでは「Web」デザイナ、「Web」エンジニアである。Webにとんと疎い私としては、そこはまったくの異文化圏である。そこでの交流は、なかなか刺激的であった。
中でも非常に新鮮だったは、普段接することのないデザイナと話す機会を持てたことだ。そして、彼らと話してわかったことには、どうやら彼らは、デザインがセンスだとエンジニアに思われていることに強い不満を持っているらしい。
確かに、「デザイン」というと、何だか芸術的なものを連想してしまう。実際、私もデザインはセンス、つまり才能によるところが大きいのだろうと何となく思っていた。しかし、デザイナの彼らに言わせれば、デザインには理論があり、練習によって習得できるものであって、したがってデザインはスキルであるという。
ここでちょっと野球を考えてみる。長嶋茂雄さんといえば往年のスター選手だ。あるとき、ホームランの打ち方を聞かれた長嶋さんは、「ボールが来たら、よく見て打て」と大真面目に答えたそうだ。長嶋さんにとっては、それがホームランの理論であり、練習によって習得したということだろう。
デザイナが、デザインがセンスだというエンジニアの思い込みに不満を持つということは、その裏返しとして、彼らは、エンジニアリングはスキルだと思っているのかもしれない。しかし、この思い込みが必ずしも正しくないことは、プログラマなら誰もが知っている。
確かに、プログラミングには理論が存在する。ソフトウェア工学と呼ばれているものがそれだ。プログラミングの外にいる人の目には、プログラミングとはソフトウェア工学の実践であって、練習によって習得できるものと映るかもしれない。しかし、そうだとしたら、どうしてこんなにも多くのソフトウェア開発プロジェクトが失敗するのだろう？ プログラマはみんなあまりにも怠惰過ぎて、練習を怠っているということだろうか？
私が思うに、プログラミングは野球みたいなものだ。ソフトウェア工学は長嶋さんのホームラン理論に似ている。この理論は間違ってはいないが、本当にホームランを打とうとするなら、理論以外の何かが必要だ。そして、重要なことは、あの長嶋さんでさえ、毎回ホームランを打てたわけではないということだ。
交流会の後の懇親会で、私はデザイナの一人に、「エンジニアリングはスキルですか？」と聞かれた。私は、「ある部分はスキルでしょう。しかし、センスが必要な部分もたくさんありますよ」と答えた。この時は酔っ払っていたのでうまく説明できなかったが、私が言いたかったのは、つまるところエンジニアリングとはホームラン理論だということだ。
だから、デザイナは、自分たちがやっていることがスキルかセンスかなんて悩む必要はないと思う。たぶん、デザインもホームラン理論だ。部外者から見るとセンスに見えるかもしれないが、実際にはスキルとセンスの混合物なのだろう。
最後に、今回の交流会を主催し、そして私を呼んでくれたSetsucoCMSのみんなにお礼を言おう。彼らはとても若く、パワフルで、情熱に溢れている。そして何より、彼らはものづくりに対してとても真面目である。彼らの今後の活躍には私は大きく期待するし、また、今後もこういった交流会に呼んでほしいと思う。
電子書籍は安い？
Amazon Kindleの日本語版が年内登場とか言っている。日本でも書店や出版社などが独自に電子書籍を出していたが、各社ばらばらで足並みが揃っていないようで、私は買い控えていた。Kindle DXですでに英語版を利用している身としては、今回のAmazonの発表は非常に嬉しい。もっとも、私のKindle DXで日本語書籍が読めるのかという心配はある。400ドルもしたのに…。
よく、電子書籍の値段はいくらが適当かという話題を見かける。書店や出版社も、適正な価格付けに困っているのかもしれない。消費者にとっては、中間に書店や卸業者が入らない分、電子書籍は紙の書籍に比べるとコストが安いように思える。したがって、当然、電子書籍の値段は紙の書籍より安くしろということになる。実際、Amazon.comのKindle書籍は、紙の書籍に比べて圧倒的に安い。
しかし、ちょっと待ってほしい。モノの値段というのは、はじめに利益ありきで決まるものではない。物の値段は、「消費者がいくらなら買うか」によって決まるものではないのか？ 消費者が１万円出してでもほしいと思うものなら、たとえ原価が100円であっても1万円で売っていいはずだ。だから、いったん中間の書店や卸業者のことは忘れて、いくらなら電子書籍を買うか考えてみよう。
私が英語版Kindleを使っていて、これは便利だと感じた機能はざっと以下のようなものだ：
まず、1についてだが、これは紙の書籍でも可能だ。媒体が何であろうともコンテンツは同じはずだからだ。また、2と3も、従来から紙の書籍で我々がやってきたことだ。ノートを取るときに本に直接書きこむのが嫌な人は、ポストイットを使うとよい。4はブックマークで代用できる。
では、5と6はどうか？ 私のKindle DXは9.7インチある。重量もそこそこで、通勤電車でつり革に掴まって読書するには大きすぎる。そこで、私は電車内ではスマートフォンで読んでいる。会社に着けばPCがあるので、PC版を使うことができる。そして、素晴らしいことに、これらはすべて同期されているのである。実際、私は、通勤時にKindleで読書をするのに、ポケットにスマートフォンを入れているだけでKindle端末や、それを入れるかばんは持ち歩かない。
これが紙の書籍だったらどうか？ 文庫や新書であれば電車の中でも読むことはできる。しかし、分厚い技術書の場合、つり革に掴まったまま読むのは難しいだろう。もちろん、紙の本は会社でも読むことができるが、家で続きを読みたいのなら、持って帰らなければならない。そして、本を持ち運ぶためにはかばんが必要だ。したがって、紙の本は電子書籍より不便そうだ。
次に７だ。検索といえば、ディジタルのお家芸である。もちろんKindleでも可能であるが、全文検索しているのか、それとも事前に決めてあるキーワードのみ検索しているのかはちょっとわからない。もっとも、全文検索したとして、どれだけ意味のある結果が得られるかは疑わしいが。
一方、紙の書籍の方は、後ろに付いている索引が検索に相当するだろう。索引は、ご存知の通り、事前に決めてあるキーワードのみが記されている。ただし、最近の本はそうでもないようだが、稀に、索引に記されているキーワードの少ない、あるいはそもそも索引自体のない書籍が存在する。技術書でこれをやられると非常に困る。というわけで、検索についても、電子書籍に歩があると言っていいだろう。
次に、8と９である。これは、言うまでもなく電子書籍の勝利だろう。技術書や技術系の教科書は分厚いものが多い。特に洋書はそうである。アメリカの学生などは、あんなに分厚い教科書を毎日学校まで持っていくのだろうか？ そして、分厚いということは、当然保管場所に困るということなのだ。その点、電子書籍であれば保管場所はまったく問題にならない。そもそも、データをローカルに保管する必要すらない。Kindleの場合だと、ノートやブックマークも含めて、すべてAmazonのサーバ上に管理されている。
最後に、10だ。誤植などは本にはつきものである。これは、紙だろうと電子だろうと変わらない。紙の場合は、誤植があった場合、正誤表をWebサイトなどで公開することになる。この正誤表の問題点は、公開されたことがわからないことだ。何となく出版社のサイトを見ていて正誤表に気づくことがある。
一方、電子書籍であれば、アップデートをネット経由で配布すればよい。誤植が発見された時点で、逐次配布することができる。実際、私の持っているKindle書籍の1冊は、端末付属の3G回線を介してアップデートされた。事前にアップデートに関するメールもきたし、大変満足している。したがって、この点も電子書籍のほうが便利だ。
さて、こうして電子書籍と紙の書籍を比べてみると、電子書籍のほうが消費者にメリットがありそうだ。もちろん、紙の書籍にも良い点があるということは私も認識している。例えば、芸術的な装幀や、芸術的な装幀や…うーん…そうだ、乱暴な扱いにも強い！
だが、一般的な読書であれば、少なくとも私は電子書籍を好むだろう。だから、私は電子書籍を安くしろとは言わない。紙の書籍と同じか、あるいはちょっと高くても電子書籍を選ぶ。実際、電子書籍には、サーバの運用や、原価より低く設定された端末本体の値段（カミソリ本体とカミソリの刃の話と同じだ）など、紙の書籍にはなかったコストもかかっているのだ。
電子書籍の値段を考えるとき、これらのメリットを中心に考えれば、自ずと適当な値段がわかるだろう（上記のように、私の答えは、紙と同等かちょっと高くてもよい）。書店や出版社の立場で考えると、電子書籍でできることを更に増やせば、これはつまりサービスを充実させることであるから、値段を上げてもよいだろう。
もう何十年も前から、これからは電子書籍の時代だと言われてきたが、ようやくその時代がやってきた。電子書籍を中心に、本のあり方というのも変わってくるのかもしれない。なお、出版社や書店が、どうしても電子書籍を紙の書籍より安くするというのなら、私はもちろん大歓迎である。
よく、電子書籍の値段はいくらが適当かという話題を見かける。書店や出版社も、適正な価格付けに困っているのかもしれない。消費者にとっては、中間に書店や卸業者が入らない分、電子書籍は紙の書籍に比べるとコストが安いように思える。したがって、当然、電子書籍の値段は紙の書籍より安くしろということになる。実際、Amazon.comのKindle書籍は、紙の書籍に比べて圧倒的に安い。
しかし、ちょっと待ってほしい。モノの値段というのは、はじめに利益ありきで決まるものではない。物の値段は、「消費者がいくらなら買うか」によって決まるものではないのか？ 消費者が１万円出してでもほしいと思うものなら、たとえ原価が100円であっても1万円で売っていいはずだ。だから、いったん中間の書店や卸業者のことは忘れて、いくらなら電子書籍を買うか考えてみよう。
私が英語版Kindleを使っていて、これは便利だと感じた機能はざっと以下のようなものだ：
- （当然ながら）普通に読書できる
- ブックマークできる
- ノートをかける
- わざわざブックマークしなくても直前にどこを読んでいたか記憶しており、次に端末を起動したとき、そのページを開いてくれる
- Kindle端末以外にも、PC、Webブラウザ、スマートフォンなどで読める
- 上記端末等で、書籍、ブックマーク、ノート、直前に読んだページを同期できる
- 検索ができる
- 1000ページを超えるような技術書でも楽に持ち歩くことができる
- 保管に場所をとらない
- 誤植等があった場合、本のアップデートができる
まず、1についてだが、これは紙の書籍でも可能だ。媒体が何であろうともコンテンツは同じはずだからだ。また、2と3も、従来から紙の書籍で我々がやってきたことだ。ノートを取るときに本に直接書きこむのが嫌な人は、ポストイットを使うとよい。4はブックマークで代用できる。
では、5と6はどうか？ 私のKindle DXは9.7インチある。重量もそこそこで、通勤電車でつり革に掴まって読書するには大きすぎる。そこで、私は電車内ではスマートフォンで読んでいる。会社に着けばPCがあるので、PC版を使うことができる。そして、素晴らしいことに、これらはすべて同期されているのである。実際、私は、通勤時にKindleで読書をするのに、ポケットにスマートフォンを入れているだけでKindle端末や、それを入れるかばんは持ち歩かない。
これが紙の書籍だったらどうか？ 文庫や新書であれば電車の中でも読むことはできる。しかし、分厚い技術書の場合、つり革に掴まったまま読むのは難しいだろう。もちろん、紙の本は会社でも読むことができるが、家で続きを読みたいのなら、持って帰らなければならない。そして、本を持ち運ぶためにはかばんが必要だ。したがって、紙の本は電子書籍より不便そうだ。
次に７だ。検索といえば、ディジタルのお家芸である。もちろんKindleでも可能であるが、全文検索しているのか、それとも事前に決めてあるキーワードのみ検索しているのかはちょっとわからない。もっとも、全文検索したとして、どれだけ意味のある結果が得られるかは疑わしいが。
一方、紙の書籍の方は、後ろに付いている索引が検索に相当するだろう。索引は、ご存知の通り、事前に決めてあるキーワードのみが記されている。ただし、最近の本はそうでもないようだが、稀に、索引に記されているキーワードの少ない、あるいはそもそも索引自体のない書籍が存在する。技術書でこれをやられると非常に困る。というわけで、検索についても、電子書籍に歩があると言っていいだろう。
次に、8と９である。これは、言うまでもなく電子書籍の勝利だろう。技術書や技術系の教科書は分厚いものが多い。特に洋書はそうである。アメリカの学生などは、あんなに分厚い教科書を毎日学校まで持っていくのだろうか？ そして、分厚いということは、当然保管場所に困るということなのだ。その点、電子書籍であれば保管場所はまったく問題にならない。そもそも、データをローカルに保管する必要すらない。Kindleの場合だと、ノートやブックマークも含めて、すべてAmazonのサーバ上に管理されている。
最後に、10だ。誤植などは本にはつきものである。これは、紙だろうと電子だろうと変わらない。紙の場合は、誤植があった場合、正誤表をWebサイトなどで公開することになる。この正誤表の問題点は、公開されたことがわからないことだ。何となく出版社のサイトを見ていて正誤表に気づくことがある。
一方、電子書籍であれば、アップデートをネット経由で配布すればよい。誤植が発見された時点で、逐次配布することができる。実際、私の持っているKindle書籍の1冊は、端末付属の3G回線を介してアップデートされた。事前にアップデートに関するメールもきたし、大変満足している。したがって、この点も電子書籍のほうが便利だ。
さて、こうして電子書籍と紙の書籍を比べてみると、電子書籍のほうが消費者にメリットがありそうだ。もちろん、紙の書籍にも良い点があるということは私も認識している。例えば、芸術的な装幀や、芸術的な装幀や…うーん…そうだ、乱暴な扱いにも強い！
だが、一般的な読書であれば、少なくとも私は電子書籍を好むだろう。だから、私は電子書籍を安くしろとは言わない。紙の書籍と同じか、あるいはちょっと高くても電子書籍を選ぶ。実際、電子書籍には、サーバの運用や、原価より低く設定された端末本体の値段（カミソリ本体とカミソリの刃の話と同じだ）など、紙の書籍にはなかったコストもかかっているのだ。
電子書籍の値段を考えるとき、これらのメリットを中心に考えれば、自ずと適当な値段がわかるだろう（上記のように、私の答えは、紙と同等かちょっと高くてもよい）。書店や出版社の立場で考えると、電子書籍でできることを更に増やせば、これはつまりサービスを充実させることであるから、値段を上げてもよいだろう。
もう何十年も前から、これからは電子書籍の時代だと言われてきたが、ようやくその時代がやってきた。電子書籍を中心に、本のあり方というのも変わってくるのかもしれない。なお、出版社や書店が、どうしても電子書籍を紙の書籍より安くするというのなら、私はもちろん大歓迎である。
