x86でOSを表現する方法
というわけで、x86系のkernelの話をしてください
とりあえずマルチタスクの実現方法について、です。
TSSディスクリプタを切り替えることでハード的にマルチタスクを
実現するのがいいのか、ひとつのTSS上でソフト的にマルチタスク
を実現するのがいいのか語ってください。
あっ、あとこのスレは馴れ合い禁止です。
終始、殺伐を心がけてください。 サクラ大戦やってるやつはデブメガネ率80パーセント以上。 >>1
そういう高度な話は2chのアホどもには無理です。
というわけで
------------ 糸冬 了 --------------- 何気に良スレの予感です。
Linux、L4系はソフト的にマルチタスクを実現してるよね。
また、OMICRON(だったような)もソフト的にマルチタスクを
実現しています。
ttp://www.os-omicron.org/index-j.html i386で、というのなら、TSS切り替えにするべき。
HWにできることをSWでやるのは、愚かというものです。
JavaのようなOSを目標とするならともかく、特定のアーキテクチャを対象としているのですし。 まずOSを定義しましょう。
ここでいうOSとはカーネルのことであり、マイクロカーネル、
モノリシックカーネルのどちらでもかまいません。
また、組み込みなどのハードリアルタイムカーネルでは
なく高スーループットのサーバ用のカーネルを前提として
話をすすめてください。 >>10
まず言っておきますが、
特定のCPUマイクロアーキテクチャを対象とする、
ということと HW or SW にするということはまったく
無関係です。
要は、タスク間の排他性を保障し、高スループットを
弾き出すカーネルにするにはどちらがいいかということです。
>12
だからなんでお前は何も語らないんだ?
しかもなんでいちゃもん付けてるんだ?
>>10
JavaをOSとか言ってるキティー発見! >>16よ
じゃあMSXエミュレータはOSなのか?
アホは黙ってMXでもやってろ。 >17
おい、ひょっとして煽りじゃなくてマジだったのか?
(((((;゚Д゚))))ガクガクブルブル
「JavaのようなOS」=「Javaマシン上のOS」
OK?
それぐらいわかってやれ。
エミュがOSかどうか、というのに意見を言うとスレが無駄に消える上に
結局結論がでないからスルー。 > 「JavaのようなOS」=「Javaマシン上のOS」
ウケタよ。
なるほどね、それをイコールできる>>18の
日本語能力も大したもんだよ(藁 >18
中卒決定だな。
エミュがOSかどうかで悩むアボ〜ンがいまだいたとは
驚きだよな。
エミュ→マシンの物理的インタフェイスの提供
OS→マシンの論理的インタフェースの提供
どを?結論出ちゃったでしょ。提供しているフレームが全然ちがうのね。
もっと勉強しなさい(藁 ほう。
物理的インターフェースと論理的インターフェースの
具体的な違いを教えてもらいたいものですな。
物理的インタフェースの提供
=マイクロコードレベルでのインタフェースの提供
論理的インタフェースの提供
=タスク(プロセス)、スレッド、仮想記憶などのインタフェースの提供
で、いいですかね>21 >24
ん?
それはCPUエミュレータだけに焦点をしぼってるだろ?
エミュレータ内でのMMUへのアクセスと
アプリケーションのOSのメモリマネージャへのアクセスの違いは? >>26
ハァ?もう一度自分が書いた文書、よんでみ。 >26
の言いたいことは俺なりに解釈してみるとだな、
>エミュレータ内でのMMUへのアクセス
↑アドレス変換が仮想記憶だと言いたいわけで、
>アプリケーションのOSのメモリマネージャへのアクセス
↑という風につながっていると思われます。 マルチタスクをソフト的に処理するとタスクとスレッドの
違いはメモリ空間が排他的かどうか?しかなくなるよな。
そっちの方が設計的にスマートかもな。 >>29
タスクはスレッドをひとつだけもつものとして定義し
スレッドに対してタスクスイッチをすれば良い。
漏れ的にはソフトスイッチに100ペソだな。 >27
読んだよ。もっとわかりやすく書こう。
OSってのはアプリに仮想マシンを提供している。
エミュレータもアプリに仮想マシンを提供している
違いは「I/O」と呼ぶか「API」と呼ぶか。
ワンクッション置くかどうかという違いは大した違いではない。
直接実機のI/O叩くエミュもOSの上に存在する「OS」も存在したはずだ。 IA-32プロセッサはTSSディスクリプタを切り替える際、かなりの
チェックなどを行うがそれをソフト的に処理するにはオーバーヘッドが
大きすぎるのではないだろうか。
>>32
IA32プロセッサのチェック機構は4段のリング構造を前提としている
のでかならずしもすべてのチェックは必要ないと思います。
物理的なインタフェース上に構築する論理的なインタフェースがOS >33
VMWare。
まぁ、VMWareがOSだとは誰も思ってないと思うが。 スマソ。
「JavaのようなOS」=「Javaのような可搬性のあるOS」
のような気がしてきた。 OSASKとかNOWSOSはどうマルチタスクを実現しているのかな?
激しくスレ違いでスマソ >38よ、お前の言うJavaはJavaVMなのかJava言語なのか、
どっちなんだ? >40
ん?言語のほうじゃねーか?
少なくとも俺は言語の方だと読んだ。
何にしろ本人が言いたかったのは
「高級言語レベルでの移植性の高いOS」的なものだと思うが。 つまりJavaのオブジェクトコードが可搬性があるから
そんなオブジェクトコードのようなOS、という意味で
JavaのようなOSと言ったわけか?
まぁ、なんにしろ18の日本語能力は最悪なことだけは確かだ。 >42
わけか?と聞かれても困るがな。正確には>10に聞いてくれ。
まあなんにしろ>40の意志疎通力が最悪なことだけは確かだ。 早起きしてしまいました。
ソフトによるマルチタスクの実現派の方が
多いですね。実際、TSSディスクリプタの切り替えで
ハード的にマルチタスクの実現をやっているカーネルは
私も知りません。ただ、OSA○Kではハード的にやってる
という話を聞いたことがあります。実際のところはわかり
ませんが・・・。
私の調べた限りですが、ハード的にマルチタスクを実現する
方法を取るとプリエンプティブなカーネルは実装が難しそう(無理かも)です。
したがって、ハード的なマルチタスクでモノリシックカーネル
を実現するのはバッドな組み合わせな気がします。
(理由はカーネルからCPUが帰ってくる時間を保証できないから)
まともなOSなら多少なりとも移植性を考慮するはずなので
特定のプロセッサアーキテクチャにしかないような機能は極力使わないのは常識。
以上。
エミュレータの話で殺伐と盛り上がっているようですが、
ここでひとつ面白いエミュレータの形を紹介したいと思います。
既に良くご存知かと思いますが、OSA○Kは(広義)OSレベルで
エミュに対応しようとしています。
具体的な形はまだ見えてきませんが注目です。
ここでシステムを階層化して考えたいと思います。
【 第5層 :アプリケーション 】
【 第4層 :ライブラリ 】
【 第3層 :サブシステム 】
【 第2層 :カーネル 】
【 第1層 :ハードウェア 】
通常、OSとは2,3,4層のことを言います。
なお世界的OSメーカのM$社では5層も含むようです。
モノリシックカーネルの場合は2,3層、
マイクロカーネルの場合は2層を通常は指します。
エミュレータとは5層で1層を実現するソフトウェアです。
したがってOSではありません。 > まともなOSなら多少なりとも移植性を考慮するはずなので
> 特定のプロセッサアーキテクチャにしかないような機能は極力使わないのは常識。
最近のOS開発の流行は移植性をカーネルより上の層に求めます。
カーネル自体の移植性を考慮して設計されたカーネルとしてMachが
あげられます。複雑なIPCプロトコルによる遅いメッセージ通信機構、
Mach以降に登場するマイクロカーネルはCPUアーキテクチャに依存する
ものがほとんどです。これらを総称して第2世代マイクロカーネルと
呼びます。つまりMachは第1世代というわけです。 >>51
QNXとかそういう発想で作られているよね。 ttp://www.os-omicron.org/~takano/doc/context.html >>53
ソフトウェア・コンテキスト・スイッチングが早いというのも
あやしいなぁ。Pen4でもそうだけど今後のCPUってさ、大容量の
キャッシュ搭載して、でもってデコード済みのコードをキャッシュ
するようになるから、・・・・・
んーん、私的にはハードウェア・コンテキスト・スイッチングに100リラだよ。 誰か解説してくれ!
--------------------------------------------
TSSの制限:
・104バイトのメモリを一度にロード,アンロードする必要があり,遅い。
・プロセスのカーネルスタックとタスク状態が,カーネルアドレス空間に存在しない。
・各プロセスのスタックが,アクティブ時に同じ仮想アドレス空間に存在する。
・ネスト可能な配置の複数プロセスからなるスレッド群を構築できない。
・プロセス終了時に,終了しようとしているコンテクストでアドレス空間を復元できない。 > ・104バイトのメモリを一度にロード,アンロードする必要があり,遅い。
104バイトというのは32bitTSSのサイズですね。
32bit * 26 = 104byte
> ・プロセスのカーネルスタックとタスク状態が,カーネルアドレス空間に存在しない。
セグメントモデルからくるものでしょう。これについては良く分かりません。
> ・各プロセスのスタックが,アクティブ時に同じ仮想アドレス空間に存在する。
これも上と同じでセグメントモデルからくるものかと思います。
> ・ネスト可能な配置の複数プロセスからなるスレッド群を構築できない。
IA32プロセッサが提供するTSSを使ったタスクはリカーシブではありません。
よってネストができません。この辺はTSSディスクリプタのBフラグの働きを調べて
みてください。
> ・プロセス終了時に,終了しようとしているコンテクストでアドレス空間を復元できない。
これは良くわかりません。 このスレを作った理由を書きます。
カーネル設計においてアーキテクチャに依存しない情報というのは
たくさんあるのですが、アーキテクチャに依存する情報というのは
あまりありません。私はx86アーキテクチャは今後も長く使われると
考えています。現にintelの設計者は今後最低でも10年、開発が継続
されるとインタビューで答えています。
IA64があまり注目を浴びないのはIA32から移行にかかるコストが膨大
だからだといわれています。それにエンドユーザにとってみれば
CPUの命令体系などはどうでもいいことです。移行に膨大なコストを
費やすことなど望んでいません。今、社会のインフラにITがどんどん
導入されています。x86の命令体系は今後も末永く使われるでしょう。
そこで、x86に依存するカーネルの設計について情報をあつめようと
思いました。散らばっていた情報をひとつにまとめることでOS開発者に
役に立てるようにしたいと思います。
何か知っている情報などありましたら書き込んでください。
また、有用な情報が記載されたHPやMLのURLを教えてください。 > まとめることで、競争が減りますよ。
レベルの低い競争は減るでしょうね。
よりハイレベルな競争になると思いますよ。
まぁ、ここで集めようと思っているのは
実装面の情報ですから。OS開発者の方には
それより上のフレームで競争してほしいものです。 >59
いや、実装できることはかなり重要。
コンピュータの世界に限っては、実装できる人は、理論もできる。
理論ができても、実装できるとは限らない。
大学研究者は、実装する実力が無いから、理論しかできない場合
多し。 そもそも、実装者は、めちゃくちゃ理論は分かっています。
はっきり言って、理論にまとめる時間が無駄だから説明しないだけ。
大学研究者は、勘違い多し。 はっきり言って、コンピュータは、実証主義に尽きます。
「俺はできる」みたいなアピールを言葉巧みにしても無駄です。
できるなら、実装結果を出すべきです。
第一、実装する方が簡単なら、理論を作る片手間で実装できる
はず。
それができないのは、実装の方が実際は難しいから。
実装するのは、机上で考える以上に実力が必要です。
逆に、実装する際、機上の理論が分かってないのにできるはず
は無いです。 理屈がわからずに、ジェット機が作れる
わけがないのです。ジェット機が実際に飛んでだ時点で、
設計者の実力は実証されるのです。 本当に低レベルなプログラマーは、出来たプログラムを見れば
一目瞭然です。
自分の実力の無さを隠すために、実装が簡単であり、
大学での理論研究の方が難しいと流布するのはやめるべきです。
そんなことしてるから、日本のソフト力が弱くなるんです。
本当の実力者をちゃんと当用してないんです。
日本のOS関連の大学研究者ってびっくりするほどレベルが低いねぇ。
アメリカの大学院生ほうがレベルがはるかに高い。
まったく恥ずかしいかぎりだよ。 >65
ん?もしかして同業者(大学研究者)?
>60
禿同!
お前も大学研究者ですか? >>66
そう。中にはまともな研究者もいるんだけどね、
ほとんどがダメね。研究費使ってデカイマシン買って
よろこんだり、研究会という名目で海外旅行したりと、
ハァ・・・。そのくせ国の調査員会とかに名を連ねてる
から性質が悪い。
あぁ、愚痴っちゃったよ、スレ違いでスマソ。 OSASKはモノリシックでもマイクロでもないとか言ってますが、
その辺を ☆王子☆ に語ってもらいましょうか。
では、よろしく> ☆王子☆ >67
なんか変な構造だね。
本当に学ぼうと思ったら、大学にいるのは時間の無駄かも知れ
ない。論文とかには追われるし。あと、ポストを得るためだけ
の事柄に時間がつぶれるし。 OS研究者が大学やめたらホームレス決定だな。
俺は数学科出身だが、1年のとき先生にこう言われたよ。
修士に行くと就職難しいぞ。
博士に行くとホームレスになるしかないな。
日本は応用ばかり目がいって基礎は評価されない世界なのよ。 >70
まあ、なんでもよければ就職口はあるだろうけど、
OS 研究そのものとか、数学そのもので食っていくのは
大変でしょうね。 大学の話で悲壮感漂いつつ盛り上がっているようですが、
私も同感で大学の教員にソフトウェアのアイデア、実装、特許など
取られ身包みはがされた経験があります。
後ろから鉄砲の引き金を引くようなマネをされるとさすがに辛かった
ですね。その教員はテレビに新聞、雑誌にと、大活躍。
私の名前は一切、出ませんでした。それが原因で大学を中退。
今は親元でぶらぶらしています:-) > OSASKはモノリシックでもマイクロでもないとか言ってますが、
> その辺を ☆王子☆ に語ってもらいましょうか。
OSASKのことは存在を知っている程度でよくわかりません。
OSASKとは切り離した形でモノリシックカーネル(以下、モノ)と
マイクロカーネル(以下、マイクロ)について語らせてもらいます。
これに関してはカーネル空間に含める含めないの議論が
されてきましたが、これは本質的ではないと思います。
要は水平アーキテクチャか垂直アーキテクチャかの違いだと思います。
一般的な汎用OS(WinであれUNIXであれ)は、モノとマイクロの
中間的な存在です。要はどちら側に寄っているか、ということです。
垂直アーキテクチャ:
【 第4層 :アプリケーション 】
【 第3層 :サブシステム 】
【 第2層 :カーネル 】
【 第1層 :ハードウェア 】
水平アーキテクチャ:
【 第3層 :サブシステム 】【 第4層 :アプリケーション 】・・・・
-----------------------------------------------------------------
【 第2層 :カーネル 】
【 第1層 :ハードウェア 】
なんかうまく表現できたとは思いませんが、マイクロの場合はカーネルより
上はすべて横並びなわけです。AS/400などは水平アーキテクチャと垂直アーキテクチャを
意識した設計となっています。「Inside the AS/400」などをごらんください。 日立のOS
ttp://www.hitachi.co.jp/Prod/comp/soft1/hmpp/mppg0001.htm
TRON系
ttp://www.ertl.ics.tut.ac.jp/TOPPERS/
OSの資料
ttp://bw-www.ie.u-ryukyu.ac.jp/~kono/os/
ttp://csr200.ipc.miyakyo-u.ac.jp/users/c8958/os/
その他(?):
ttp://bizit.nikkeibp.co.jp/it/linux/opensource/contents/contents.html >>69 >>70
激しく同意。
漏れはコンピュータで言語学をやりたかったけど
くそつまらん雑用にうんざりして大学をやめた。
今はフリーターだがほされたらホームレス決定。
>>78
人生の敗北者ハケーソ
OS板にいるってことは、どうせRubyとか使ってたんだろ(激藁嘲笑 OS板にいる = RUBY ?
ハァ?わけがわからんな。 お前ら一度しか言わんから耳かぽじって良く聞け!これが真理だぜ。
大学まともに続けているようなやつに大物はいない。
大学まともに続けているようなやつは大物になれない。
ちなみに↑これ、どっかの会社のCEOの発言ね。 >私も同感で大学の教員にソフトウェアのアイデア、実装、特許など
>取られ身包みはがされた経験があります。
アイデアは提供してもされた方が得するだけ。(言い損。)
とっておきの物なら絶対他人どころか身内にも話してはだめ。
本当にやるなら自分でやらなきゃね。(独立を思考中の者より。)
押菌>unko!
達悪>unko!
押菌>FAQ U
達悪>U 大!
押菌>∫Ηinё!
達悪>κΙ┗┗ U!
押菌>μηκο!
達悪>μηκο! >>90
μηκοじゃなくてομηκοだろ!
東京ではομανκοって言うが。 >>91
ギリシア語の正書法では鼻濁音をガンマで表記します。
→ ομαγκο ( ・∀・) | | ガッ
と ) | |
Y /ノ 人
/ ) < >__Λ∩
_/し' //. V' A `)/
(_フ彡 / ←>>94 ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━― ∧_∧
ピュ.ー ( ^^ ) <これからも僕を応援して下さいね(^^)。
=〔~∪ ̄ ̄〕
= ◎――◎ 山崎渉
__∧_∧_
|( ^^ )| <寝るぽ(^^)
|\⌒⌒⌒\
\ |⌒⌒⌒~| 山崎渉
~ ̄ ̄ ̄ ̄ ∧_∧ ∧_∧
ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。
=〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
= ◎――――――◎ 山崎渉&ぼるじょあ