4: 2009-11-17 (火) 12:08:10  |
現: 2024-01-08 (月) 12:58:55 k-tan |
| - | * OS開発の方向性 | + | TITLE:x |
| | + | * OS開発の方向性 [#s10aed81] |
| | -(by [[K]], 2009.01.03) | | -(by [[K]], 2009.01.03) |
| - | *** (0) | + | *** (0) [#o1b5bbfe] |
| | -これは当初「川合のぼやき」に書こうかどうか迷った内容のものを書くことにしたわけだけど、ここは僕のホームページではなくOsaskWikiなので他の誰が書いてもいいものだと思う。 | | -これは当初「川合のぼやき」に書こうかどうか迷った内容のものを書くことにしたわけだけど、ここは僕のホームページではなくOsaskWikiなので他の誰が書いてもいいものだと思う。 |
| | -ただこのシリーズの趣旨としては、OSASKの設計に関する話を書いているので、他の人が書く場合もそれには準じてほしい。で、僕以外の人がOSASKの設計に関する話を書くなんてことはまずないと思うかもしれないけど、そんなことはなくて、たとえばこういう考え方のもとでこうしたらどうかという提案はできる。 | | -ただこのシリーズの趣旨としては、OSASKの設計に関する話を書いているので、他の人が書く場合もそれには準じてほしい。で、僕以外の人がOSASKの設計に関する話を書くなんてことはまずないと思うかもしれないけど、そんなことはなくて、たとえばこういう考え方のもとでこうしたらどうかという提案はできる。 |
| | -基本的に一つの話題に1ページ使ってしまうので、ちょっとした提案であれば、OSASK-MLや[[impressions]]を活用してもらうほうがいいと思う。 | | -基本的に一つの話題に1ページ使ってしまうので、ちょっとした提案であれば、OSASK-MLや[[impressions]]を活用してもらうほうがいいと思う。 |
| - | *** (1) | + | *** (1) [#wa7e00a0] |
| | -これを読んだ（これに限らず.mjtさんの日記は興味深い話題が多いと思う）。 | | -これを読んだ（これに限らず.mjtさんの日記は興味深い話題が多いと思う）。 |
| | --http://d.hatena.ne.jp/mjt/20090103/p3 | | --http://d.hatena.ne.jp/mjt/20090103/p3 |
| | -この話を読むと分かるとおり、独自のファイルシステムを作って、そこで既存のアプリケーション（gccやbashやm4）を動かすことになっている。つまり独自のアプリケーションを動かすことは主たる目的ではないのだ。カーネルをXen上に構築することで分かるように、ドライバを作ることも目的ではないのだ。またXを移植するというところで分かるとおり、独自の新しいウィンドウシステムを作ろうという気もないらしい。・・・僕はそれを批判したいわけじゃない。OSを作る目的は人によってさまざまだ。ファイルシステム重視で作るというのは非常に有力な一つの候補だし、それは他の目的と比べてなんら劣ってなんかいない。僕が今言いたいのは、でもそれでOS開発全般を語ったことにはなっていないということを指摘しておきたいだけだ。 | | -この話を読むと分かるとおり、独自のファイルシステムを作って、そこで既存のアプリケーション（gccやbashやm4）を動かすことになっている。つまり独自のアプリケーションを動かすことは主たる目的ではないのだ。カーネルをXen上に構築することで分かるように、ドライバを作ることも目的ではないのだ。またXを移植するというところで分かるとおり、独自の新しいウィンドウシステムを作ろうという気もないらしい。・・・僕はそれを批判したいわけじゃない。OSを作る目的は人によってさまざまだ。ファイルシステム重視で作るというのは非常に有力な一つの候補だし、それは他の目的と比べてなんら劣ってなんかいない。僕が今言いたいのは、でもそれでOS開発全般を語ったことにはなっていないということを指摘しておきたいだけだ。 |
| | -独自のウィンドウシステムを作りたくてOSを作る人もいる。独自のAPIを作りたくてOSを作る人もいる。とにかくカーネルを書きたいという人もいる。カーネルなんてその辺から流用してしまえばいいという人もいる（L4カーネルを使って独自OSを作るとか）。デバイスドライバを書くのが楽しくてしょうがないという人もいる。 | | -独自のウィンドウシステムを作りたくてOSを作る人もいる。独自のAPIを作りたくてOSを作る人もいる。とにかくカーネルを書きたいという人もいる。カーネルなんてその辺から流用してしまえばいいという人もいる（L4カーネルを使って独自OSを作るとか）。デバイスドライバを書くのが楽しくてしょうがないという人もいる。 |
| - | *** (2) | + | *** (2) [#g63f8b6a] |
| | -さてここからがむしろ本題なのだけど、じゃあ僕はどうなのか、OSASKはどうなのか。それを整理してみようと思う（というかそれがなければこの話題はOsaskWikiにふさわしくない・・・笑）。そしてそれをやってみたら、なかなか興味深い分析ができそうな気がする。 | | -さてここからがむしろ本題なのだけど、じゃあ僕はどうなのか、OSASKはどうなのか。それを整理してみようと思う（というかそれがなければこの話題はOsaskWikiにふさわしくない・・・笑）。そしてそれをやってみたら、なかなか興味深い分析ができそうな気がする。 |
| | -僕はとにかく究極的に効率のよい状態がほしい。古いPCも新しいPCもその能力を余すことなく出し切れている状態がいい。特に古いPCが能力を出し切っていないのに、つまり本当はまだまだ現役でやれるのに、それなのに無能力の烙印を押されて破棄されていくのは嫌いだ。 | | -僕はとにかく究極的に効率のよい状態がほしい。古いPCも新しいPCもその能力を余すことなく出し切れている状態がいい。特に古いPCが能力を出し切っていないのに、つまり本当はまだまだ現役でやれるのに、それなのに無能力の烙印を押されて破棄されていくのは嫌いだ。 |
| | -僕はとにかく効率のよい状態がほしい。そして効率を究極的にまで高めるためには、結局全ての部分を高効率なものに置き換えなければいけない。ファイルシステムだけ作り変えればいいわけじゃない。とりあえずここまででAPIとアプリについては解決できたとしよう。それでもドライバやカーネルやシェルやファイルシステムやウィンドウシステムや・・・それこそいくらでもある。.mjtさんの提案のように、適当に既存のものを流用できるのならしたいくらいだけど、そういう流用は結局は「とりあえず動いただけ」になってしまうことが多く、とても高効率とはいえない。動くだけでいいのならそもそもOSなんか作る必要がないのだ、僕の場合は。OSを作ることそのものは目的じゃないから、そんな効率の低いもので我慢できるのならわざわざOSを作るまでもなく、Windows上やLinux上でefg01していれば用は済む。 | | -僕はとにかく効率のよい状態がほしい。そして効率を究極的にまで高めるためには、結局全ての部分を高効率なものに置き換えなければいけない。ファイルシステムだけ作り変えればいいわけじゃない。とりあえずここまででAPIとアプリについては解決できたとしよう。それでもドライバやカーネルやシェルやファイルシステムやウィンドウシステムや・・・それこそいくらでもある。.mjtさんの提案のように、適当に既存のものを流用できるのならしたいくらいだけど、そういう流用は結局は「とりあえず動いただけ」になってしまうことが多く、とても高効率とはいえない。動くだけでいいのならそもそもOSなんか作る必要がないのだ、僕の場合は。OSを作ることそのものは目的じゃないから、そんな効率の低いもので我慢できるのならわざわざOSを作るまでもなく、Windows上やLinux上でefg01していれば用は済む。 |
| | -そう考えると、なかなか道は長くて遠くて険しい。でも他にやりようがないから仕方ない。ほしいものはほしい。いくら大変そうでも、それを理由に自分にとって必要のない別の何かを作る気にはならない（大変だからあきらめるということはありえるかもしれないけど）。 | | -そう考えると、なかなか道は長くて遠くて険しい。でも他にやりようがないから仕方ない。ほしいものはほしい。いくら大変そうでも、それを理由に自分にとって必要のない別の何かを作る気にはならない（大変だからあきらめるということはありえるかもしれないけど）。 |
| - | *** (3) | + | *** (3) [#vb6c79d7] |
| | -なんと.mjtさんが早くもお返事を書いてくれた（忙しいのにどうもありがとうございます）。 | | -なんと.mjtさんが早くもお返事を書いてくれた（忙しいのにどうもありがとうございます）。 |
| | --http://d.hatena.ne.jp/mjt/20090104/p1 | | --http://d.hatena.ne.jp/mjt/20090104/p1 |
| | -いい話題だと思うので論点を整理してお返事しようと思う。まず順序を逆にしてp2のほうからいこうと思う。例によってまた引用から。 | | -いい話題だと思うので論点を整理してお返事しようと思う。まず順序を逆にしてp2のほうからいこうと思う。例によってまた引用から。 |
| | 要するに、 | | 要するに、 |
| | + | |
| | あのリストは、「今後近代的なPCで動作するOSを製作するために必ず通る道」を挙げたもので、 | | あのリストは、「今後近代的なPCで動作するOSを製作するために必ず通る道」を挙げたもので、 |
| | デバイスドライバを作るとか、Windowsystemを作るとかはこれらの『後』に来ることを想定している。 | | デバイスドライバを作るとか、Windowsystemを作るとかはこれらの『後』に来ることを想定している。 |
| | + | |
| | もちろん、あのリストを誰かが代表して埋めて、フレームワークとして共通化するのも | | もちろん、あのリストを誰かが代表して埋めて、フレームワークとして共通化するのも |
| | 方向性としては想像できる。 | | 方向性としては想像できる。 |
| | + | |
| | コンパイラがself-hostingにならなければならない理由は、Linuxのカーネル以外に依存する | | コンパイラがself-hostingにならなければならない理由は、Linuxのカーネル以外に依存する |
| | デザインにするとHypervisorとLinuxユーザランドの両方に依存してしまうため。 | | デザインにするとHypervisorとLinuxユーザランドの両方に依存してしまうため。 |
| | -さて次はp1のほうを。まずはやっぱり引用。 | | -さて次はp1のほうを。まずはやっぱり引用。 |
| | API or Language(なぜAPIでなくてファイルシステムなのか) | | API or Language(なぜAPIでなくてファイルシステムなのか) |
| | + | |
| | 個人的には、究極に効率的なシステムのためにも、APIを決めることよりも「記述環境」を | | 個人的には、究極に効率的なシステムのためにも、APIを決めることよりも「記述環境」を |
| | 作ることに意義が有ると考えている。 | | 作ることに意義が有ると考えている。 |
| | + | |
| | システムとして出荷されたときのバイナリサイズよりも、実行時に占めるメモリサイズのほうが | | システムとして出荷されたときのバイナリサイズよりも、実行時に占めるメモリサイズのほうが |
| | 多分重要で、そのためには必要な部分だけをロードするといった対策が必要になる。 | | 多分重要で、そのためには必要な部分だけをロードするといった対策が必要になる。 |
| | 出荷されたときのバイナリサイズにしても、部品の共通化を進めるのは良い影響を与える。 | | 出荷されたときのバイナリサイズにしても、部品の共通化を進めるのは良い影響を与える。 |
| | + | |
| | (少なくとも、僕の知識ではAPIコールの効率性とシステムの効率性を関連付けられない) | | (少なくとも、僕の知識ではAPIコールの効率性とシステムの効率性を関連付けられない) |
| | + | |
| | そもそも、現代的なシステムではプログラムよりもデータの方が圧倒的に大きな存在感を占めている。 | | そもそも、現代的なシステムではプログラムよりもデータの方が圧倒的に大きな存在感を占めている。 |
| | メモリからキャッシュへのコピー、データの配列、そのほかのI/Oがシステムの速度を決定付けている。 | | メモリからキャッシュへのコピー、データの配列、そのほかのI/Oがシステムの速度を決定付けている。 |
| | + | |
| | (もし必要なら、)良くデザインされたファイルシステムはこの側面にアプローチできる。 | | (もし必要なら、)良くデザインされたファイルシステムはこの側面にアプローチできる。 |
| | + | |
| | ただ僕の主張としてより重要なのは、APIはプログラマにしか触れないけれどファイルシステムは | | ただ僕の主張としてより重要なのは、APIはプログラマにしか触れないけれどファイルシステムは |
| | ユーザ全員が触るという点で、より端的に表現すれば「多くのプログラミングは | | ユーザ全員が触るという点で、より端的に表現すれば「多くのプログラミングは |
| | 本来プログラムの外部で行われる必要が有る」。 | | 本来プログラムの外部で行われる必要が有る」。 |
| | + | |
| | 一つ一つのプログラムを小さくすることよりも、プログラムの数そのものを減らした方が | | 一つ一つのプログラムを小さくすることよりも、プログラムの数そのものを減らした方が |
| | 効率的に思える。 | | 効率的に思える。 |
| | -最後に「APIコールの効率性とシステムの効率性を関連付けられない」について。これは結局は簡単な話だ。たとえばある出力を得るために、100ステップの工程が必要なシステムと10ステップの工程だけでできるシステムがあれば、どちらが効率的だろうか。これを論じるには、それぞれのステップの処理時間をつぶさに比較しなければ正確なことは言えない。しかし第一近似として、10ステップのほうが効率はよさそうだということはできる。そして僕が言っているのも結局はその程度だ。それ以上の精度を出すにはベンチマークなどをやるしかない。・・・近似を否定して関連性は全くないとして片付けてしまうことはもちろんできるが、そこから何か得られるだろうか。僕はそれよりも近似は近似として受け入れて、役に立ちそうな場面では利用し、むしろそれが不十分であればその近似精度を上げる方法を考えたい。 | | -最後に「APIコールの効率性とシステムの効率性を関連付けられない」について。これは結局は簡単な話だ。たとえばある出力を得るために、100ステップの工程が必要なシステムと10ステップの工程だけでできるシステムがあれば、どちらが効率的だろうか。これを論じるには、それぞれのステップの処理時間をつぶさに比較しなければ正確なことは言えない。しかし第一近似として、10ステップのほうが効率はよさそうだということはできる。そして僕が言っているのも結局はその程度だ。それ以上の精度を出すにはベンチマークなどをやるしかない。・・・近似を否定して関連性は全くないとして片付けてしまうことはもちろんできるが、そこから何か得られるだろうか。僕はそれよりも近似は近似として受け入れて、役に立ちそうな場面では利用し、むしろそれが不十分であればその近似精度を上げる方法を考えたい。 |
| | | | |
| - | * こめんと欄 | + | * こめんと欄 [#b673cb70] |
| | #comment | | #comment |
