実行してしまうアーティキチャを考えています。
それらのカーネルは一つの共有メモリーを持たせて、
オーバーヘッドによる低速を抑えるつもりです。
ご意見を。
i､_ __,,,-- ､ ＼ ! おまえら全員ひれ伏してください。おながいします。
!､_｀'''''-- ､:: :: ,,,,-ｰ'___,,,,,- ､ i ノ| !
i ~'ｰ-- ､ヽi. iヽ __,,-'___,,,,,,,,__ i ／｀i.i.! 帝ハ神ナリ。帝ハ神ナリ。帝ハ神ナリ。帝ハ神ナリ。帝ハ神ナリ。帝ハ神ナリ。
i<"弋~ﾞﾞ＞.iﾞ .:ﾞ:::ﾞ＜´弋~ノ,-''´ i ! i. i.i!
i ｀'ｰﾞ'´´.,i :::::: ｀'ｰ''ﾞ´ .::;ヽ! i ノ i >>1た垣 退助 お前の命に価値なんかねーよ。自由＞∞＞お前の命（藁
i i ::::: :::::::.. .::;;;;;;;;;ﾞi,ﾞi i >>3条 実美 お前のようなヘタレが本当に太政大臣なのか？（ｗ
.i, ,;i :_,,::::. ::::::.. ;;;;;;;;;;;!,,,,,,／. 大隈 >>4げ信 てめーの作った大学、お前並にDQNだな（ﾌﾟｯ
. i i. ヽ:: ::::. ;;;;;;;;;;;;;;;;;;;;;,i 西>>5う 隆盛 ガキみたいな喧嘩ごときで下野してんじゃねーよ。（笑
i. ヽi!i,__i!!!''ﾞ ::;;;;;;;::::::;;;;;;;;;;;,i 伊藤 ひ>>6文 おいおい、チョンごときに暗されんなよ（禿藁）
i ／ ,-､ ｀'-,, ::::;;;;;;;;;;,i >>7か江 兆民 アル中で議員やめて、その後の事業ことごとく失敗（ﾌﾟｯ
i／ /"''"ヽ ｀'-, :::::;;;;;;;;;;i >>8ま県 有朋 維新早々、いきなり汚職事件おこしてんじゃねーよ（藁
／__,,-'´-,,____,,-｀'-,,___＼ ....:::::;;;;;;;/ 大>>9保 利通 征韓論に反対したくせに征台するのかよ、おえでてーな（ｗ
￣ ﾞi, / ﾞi, ￣ ,;;;;-' 江>>10 新平 大久保ごときに惨敗すんなんて、お前ホント雑魚だな（笑
もっと詳しく､具体的に
http://219.173.171.38/
http://219.173.171.38/~ss.jpg
http://your-kmiajdwmaj/
http://your-kmiajdwmaj/~ss.jpg
要するにVMWare ESX Serverみたいな物？
MicroKernelアーティキチャのもと、
分離されたカーネルの機能を各ミドルウェアに実装します。
つまり、「カーネルが複数存在する」または
「カーネル(全体制御中枢)が存在しない」と表現できます。
MicroKernelといってもMachから派生するわけではありません。
仕様は複雑難解になりますが、革新的なアーティキチャになると確信しています。
☆考えられる利点☆
１．もし、Windowsのカーネル(当然このOS用にビルトしたもの)を
このOSで実行できれば、エミュレーターの数十倍ものスピードで
Windows専用のアプリケーションが実行できます。
２．中心が存在しないことは
「どの一点が停止しても全てのサービスが停止することはない」を意味します。
つまり、Linuxより協力なサーバーとして利用できます。
並列処理が強化されるので、OSは安定するはずです。
セキュリティーシステム等も強化できます。
要するにマシンを二台置けばいいってことだな？
(･∀･)ｱｰﾃｨｷﾁｬ!
(･∀･)ﾋﾞﾙﾄ!
で、その複数存在するカーネルは誰が統制すんねや。
カーネルか？
出来るだけなんとか頑張ってみます。
>>13
統制する物はありません。
カーネルからカネールへのシステムコールをもサポートします。
データは共有メモリによって最速化します。
（共有メモリは一つ）
>>12
一台で、一つのCPUで起動します。
そんなもんいらない。
http://pc.watch.impress.co.jp/docs/2005/0330/amd.htm
Pacificaは、CPUのリソースを独立したパーティションとして分割し、
その分割した各リソース上で複数のOS/アプリケーションを
動作可能な仮想化技術。単一のシステムが複数の“仮想システム”として
動作する。Pacificaのパートナー企業は、Microsoft、VMware、
XenSourceらが名を連ねる。
うはっｗｗｗおｋｗｗｗうえっうえっｗｗｗ？？
観点からして違うだろ(藁
>>1
複数の「仮想カーネル」を統べるカーネルが存在しないってことだけど、
それだとメモリ管理とかはどうやってやるんだ？
アーティキチャって何か教えてくれんかのう。
それに まともに答えようとするそぶりはないし
特に>>10の ☆考えられる利点☆ の後読めば
要するにネタじゃん って､折れも釣られた事になるなｗ
>>21ネタではありません。
しかし、完成できなかったり、実用化されなかったりしたときは
結局ネタになってしまうのかもしれませんね。
>>18アプリケーションのメモリ管理は専用のカーネルを作成します。
カーネル内でのメモリ管理は相互に監視、管理していきます。
知識で考えると矛盾するんだが､
１．> 「どの一点が停止しても全てのサービスが停止することはない」(>>10)
２．> 一台で、一つのCPUで起動します。(>>15)
３．> 統制する物はありません。(>>15)
2つのカーネルをA,Bとすると １．には①A,Bの切り替え ②A,B相互のメモリ保護､が最低必要だけ
ど統制する親カーネルなし VMでも マルチCPUでも 複数マシンでも無しに､どうやって実現するの？
今までの色んなヒトの質問を少し具体的にしただけだけど､
ここは画期的なｱｰｷﾃｨﾁｬのスレだぞ？
画期的なアーティキチャがあれば何でもできる
そんな風に考えていた時代が僕にもありました
これじゃいけない理由書いてよ。
http://pc.watch.impress.co.jp/docs/2005/0330/amd.htm
Pacificaは、CPUのリソースを独立したパーティションとして分割し、
その分割した各リソース上で複数のOS/アプリケーションを
動作可能な仮想化技術。単一のシステムが複数の“仮想システム”として
動作する。Pacificaのパートナー企業は、Microsoft、VMware、
XenSourceらが名を連ねる。
要するにPacificaの「拡張」でもあるし「原始的」な部分もある。
>>1の言ってる部分で共有メモリを用いる点では複数のカーネルを動かすのに適してる。
ただしCPUを完全に(Pacificaのようには)分割してないから「独自ビルドのカーネル」が必要。
その意味合いで「観点が違う」と言ったんだが。
>>1
例えば通常のOSではハードウェア制御のドライバがある(Windows NTではカーネルモードで動作する)訳だけど、
そのコンフリクトその他の制御はどうやってやるの？
# x86だったら単純にできそうな気もするが……
1. ２つのカーネルをA,Bとする｡
2. A,Bは独立したプロセス・スケジューラ(PSと今命名)機能を持つ
3. このPSは､ある印のついた特権子プロセスを自分と同じ特権レベルで起動する
4．AはBを特権子プロセスとして持つ､特権子プロセスは永久にPSのキューから消えない､Bも同じ
5．A,B間のはメモリを「紳士協定ｗ」で犯さない
6. AはBをbootする機能をもつ｡Bも同じ
7. 謎の機能でAはBがパニくるとそれを知ることができ､そのときはAがBをrebootする
ぐらいすれば何とかA,Bの下に何も統括するものが無くても
A,B動かすこと「だけ」はできんでもないかな （続く）
まずはA,Bそれぞれの子プロセス同士の排他制御｡
マップやスケジュール用のキューを共有したりしたら
AがアボーンしたらBも道連れで､このあーきてくちゅあのメリットはゼロ
そもそもA,Bの共有メモリて上の「7.謎の機能」以外何か使い道はあるのかいな？
しかし沢山間違ってそうだｗ つっこみよろ＞All and >>18
> ☆考えられる利点☆
> １．もし、Windowsのカーネル(当然このOS用にビルトしたもの)を
> このOSで実行できれば、エミュレーターの数十倍ものスピードで
> Windows専用のアプリケーションが実行できます。
は､「当然このOS用にビルトしたもの」だったら
カーネルがマルチかどうかはカンケーないんじゃない？つまり
○MkLinuxは､BocksやQEMU上で動かしたLinuxより速いです
○Debian GNU/Linux と Debian GNU/NetBSDは同じぐらいの速度です
○MacOSXはFreeBSDに対して速度的に遜色ありません
と同じことを言ってるように折れには見えるが？
上の違いは「Windows」互換のカーネルが独立して走る所です。
>>30
私の考えているものは全くそれです。
>>31
利用ですが、
青画面にあることを防ぐこと以外にも
Updateの利便性向上です。
WindowsではUpdateを行ったとき、
再起動を行う必要がある場合が多いですが、
これが不必要になります。
(再起動と言う言葉自体消えるかもしれません。)
また、重要システムの根本的グレードアップ
(WinMe → WinXpのような)
も、再起動が不必要になるかもしれません。
私はまだ、かなり未熟のようです...
PacificaやDARMAなどを全く知りませんでした...
教えていただきありがとうです。
ここでも書き込みは「要求」として
資料にまとめていっていますので、
ご意見どうかよろしく御願いいたします。
何でこんないい加減なモノ（>>30-32)にボロクソ突込みじゃなく「ありがとう」なんだよ（・∀・）ｶｴﾙ!!
> 再起動を行う必要がある場合が多いですが、
> これが不必要になります。
正確にはパソコンを再起動する必要が無くて、
OSだけの再起動ですむということです。
もちろんOSの再起動時にはそのOSで
動いているサービスはすべて一旦停止します。
モナーでもわかるように基礎だけでも２、３年かかっとるんだから
つくってなんぼだよ
結局再起動してるじゃん。
意味ねーｗ
全てのサービスを停止する必要はありません。
また、AとBが同じ動作をサポートするようにします。
つまり、Aが再起動中にBがAの代用をし、
Aが正常に起動すれば、Bを再起動するようにするのです。
こうすれば、ユーザーやアプリケーションから見れば、
再起動していないように見えます。
ヽ（`Д´）ﾉ ｳﾜｧｧｧﾝ
>>40がホンモノ...僕です。
説明するスレッドになってしまっていました。
ここでは僕が考えているアーティキチャについて
意見と要求を書き込んでいただきたいのです。
取り合えずトリップつけてくれ
それからメモリの紳士協定の具体的な実装はどうするつもり？
一応2個以上のカーネルを動かすのだろう
2つのカーネル間での調停用の通信機能を持たせるのか？
カーネルおよびPSの起動時は特殊なブートローダーでも使うの？
プロセスをカーネル間で移動させるってのは実現可能でもうlinuxとかで出来てるけどな
少なくとも革新的過ぎて着いていけない
BIOSは一つのカーネルしかブートできないはずなので、
BIOSから「第一のカーネル」がブートされます。
この第一のカーネルによって
他のカーネルは起動されるわけですが、
このとき、紳士協定としてメモリは配分されるようにします。
しかし、この方法だと、
他のカーネルは「第一のカーネル」によって
管理されるわけではないので、配当を増やすことは出来ません...
まだ考案中です(ﾟ∀ﾟ)
調停を「カーネル」だけで行うのには無理がある。
なぜなら、
・メモリの無駄
・対障害性が不十分
の面がで不都合が生じるから。
そうなると(機能を最小限に抑えた)「親カーネル」が必要だね。
個人的にはカーネルＡとカーネルＢが(ある程度、障害が起きた時以外でも)
協調できると良いと思う。
それではﾉｼ
>>1
>>44で書かれたように、初めにメモリを(固定的に)割り当てると、それこそESXと変わらないわけで(^^;
>>45で書いたような仕組みにして、動的に(おおまかでもいいから親カーネルが)メモリを割り当てた方が良い気がする。
矛盾している。
> 再起動するのは一部のシステムであり、
> つまり、Aが再起動中にBがAの代用をし、
> Aが正常に起動すれば、Bを再起動するようにするのです。
再起動するのは一部のシステムじゃなかったのか。
ようするにOSを二つ同時に起動しておいて
本システムをアップデートする前に副システムに切り替え
本システムをアップデートして元に戻すってことだろ。
たんなる多重化じゃん。
アップデート前にそのサービスのメモリ内に次のような構造体のデータがある。
struct FOO {
char a;
char b;
}
これがアップデート後に次のような構造体に修正される。
struct FOO {
long a;
long b;
}
>>1
さて、どうやって再起動なしに処理を続ける？
システム＝コンピュータ全体
システムの一部＝複数あるカーネルの内の一つ
と(俺は)解釈したんだが……(^^;
合ってる？>>1
動かしているのとなんの違いも無い。
マルチカーネルOSなどといっているが
エミュレータそのものである。
>>1のために(ryしとくわ(^^;
BIOSからブートローダーを読み出して2つのカーネルとPSが立ち上がるまで管理するんじゃないの
それ以降は2つのカーネル間で調停なり協定なりでメモリを配分させるんじゃない？
BIOSとブートローダー（一般的には）は違う物だよ
OS(Windows)の対応だけじゃ無理だね。
この例ではメモリのアドレスをずらすだけで可能だけど、
もしかしたらまったく違うデータ構造になるかもしれない。
これに対応するにはOSの対応とは別にアプリ自体にデータ変更機能をつけるしかない。
ユーザーに再起動をしていないように見せかけるには、
Windows等のOSが再起動しても・・・の場合は、Windows等OSを修正すればいい。
アプリケーションが再起動しても・・・の場合は、アプリケーションを修正すればいい。
よって、マルチカーネルOSなどと言うものを作る必要は無い。
それともWindowsとはまったく別のOSを作るという話か？
システムが何でサービスが何で、
どれを再起動するのかとか全然わけわからん。
文をしっかり読んでなかった、スマソorz
>>52
説明不足だった。調停とかを親カーネルなしですると
(複数カーネルの中で)同じようなコードが重複したり、(調停ルーチンの)変更が難しかったり、
調停ルーチンが間違っていたりバージョンが違ったりすると全体が落ちる可能性があったりするから
調停ルーチンを抽象化する「親カーネル」を持った方が良いのでは、と思ったわけ。
ライブラリとかの変更だと俺の解法だと無理なわけでorz
ありがと､なんか「らしく」なって来たよー
>>1
勝手に仕切るようで悪いが 頻繁にWindowsの利便性と較べる話をしてるが､
そういうのはこのOSがLinux ver.1?ぐらいになって
「Wineを載せるか､いやReactOSから､、」ぐらいになってから考えてくれない？
アナタの考えるべきは､まずマルチカーネルを成立させることでしょ｡
で､まるちかーねる､の長所としてまず確立すべきは耐障害性じゃね？>>All
そんで､まあ(>>30アーティキチャ？）で行くなら別に良いけど､このままじゃ成立しない
或いは複雑になりすぎて逆に耐障害性は落ちる等､色々指摘されてるし､
一番まっとう「普通の」解決方法は「親カーネル」､､､でもこれじゃ>>6に逆戻りっぽいし､､､
と､すると>>1さん､アナタの示すべきはこれら問題の「画期的かつシンプル」な
解決方法じゃない？
ホントにコロンブス卵がなければ､例えば天才の閃きで「バッサリ割り切る」でも良いかも
C言語とかUNIXとかも何かそんなとこもあるし､､､
なんか偉そうにすみません>>1 & >>ALL
個人的にはそれだとxenと同じで面白くないと思ったのですよ
基本的にはGRUBのようなものを起動完了まで親カーネルの役割をさせておいて
起動してから自分自身をアンロードするというものです
その後はカーネル間で調停を行っていく（この中でどちらかに調停用のプロセスを走らせて
親カーネルの役割をさせていく必要があるかもしれませんが）
それから構造体の変更については難しいですがなんとか変更できるのでそういうのをやったらどうでしょうか
（つーかシステムの基幹にかかわるようなサービスは両カーネルで走らせて置いてアップデートの時には片方を
アップデートしつつもう一方のサービスのプロセスをコピーさせてもらうとかまだ方法は幾つかあると思いますが
どちらにせよプロセス間通信などをいままで以上に複雑化しなきゃいけない…）
ごもっともですね。(少し口調変更
xenという物を(界隈に居ながら)知らなかったのでorz
おかげで別のアイデアも思い付いて来ましたし…ｗ
だからバックグラウンドでアップデートするのは簡単なんだよ。
問題は古いプロセスを使っている状態から新しいプロセスに移行する方法。
これはデータ構造が違う可能性があるので、走らせたままで移行するのはアプリ自身が
対応しない限り不可能。以前のバージョンでは存在しなかったデータが作られる場合だってある。
だからOSの変更やマルチカーネルOSとかの対応だけじゃ無理。
プロセス間通信を強化しても無理。内部データの変更はアプリ自身でしか知ることが出来ない。
逆にアプリ自身が対応するのなら、OSの変更やマルチカーネルOSなどなくても可能。
同一のハードウェア上で起動している以上
ハードウェアが壊れたときの耐障害性は期待できない。
また同一のOSが二つ起動していたとして、一つだけがソフトウェア的に
おかしくなることはありえない。
また再起動なしでアップデートとかもデータ構造の違いがあるために非現実的。
期待できるのは、独立した複数のOSを同時に起動できるという
今世間がハードウェアでやろうとしていることの遅いソフトウェア版ということだけ。
そのソフトウェア版もすでにVMWAREが実現している。
別にこれを売ろうとかしている訳じゃなくあくまで趣味しかもまだ企画段階であって
これからどんな風になるか解からんし
某ドアフォ（小規模MMO）見たいに他人に迷惑掛け捲る訳ではなさそうですし
見たいなものですかね
非常に知的興味心を満足させてくれるような企画なんで（仮想化技術のそれぞれのアプローチ自体がですよ）
>一つだけがソフトウェア的に…
同じＯＳが同じ時間に同じ処理をやるのなら有り得るけど、そういう状況にはどうしてもならないから、
微妙な違いで一つだけがハングすることは十分有り得ます。
>>63
期待してますｗ (サンプルでも実装してみようかな
そのため実装できませんｗ
つーかMONAをサンプルに借りればいいのかな？
実際かなりの量のAPIの追加も必要になるし
サンプルにMonaは敷居が高い(^^;
とりあえず、一からコード(2種類の「カーネル」＋「補助カーネル」)を組んでみます。
ただ手元にPCがないから書くのは明日以降かな。
そろそろ付いていけなくなりそうな雰囲気なので(^^;
（>>51（>>1のために(ryしとくわ(^^;））
みたいなこと言わずに色々公開してオベンキョネタを下さい
>>30さん
>>48の問題で思いついたのは、ある程度の前提条件が成り立つ上で実現できます。
・カーネルなどのシステムに近いモジュールであること
・メモリに完全に(モジュールが)ロードされていて、ディスクを弄ばないこと
・ユーザーモードが直接I/Oを叩かない事
・アップデートが単独で動作する部分に限るか、アップデートした後も他モジュールから見て変わらないこと
・動作は完全に下位互換性を持つこと
この条件のもとで、例えばカーネル(A1)を(A2)にスムーズに移行する手段を示してみます。
1. カーネル(A1)が(A1)'を起動する。 (ここでマルチカーネルの本領発揮)
2. (A1)がステートを停止できる状態になるまで待つ。
3. (A1)'に(A1)のステートを移行する。そして(A1)'が実行を開始する。
4. (A1)を(A2)に(メモリとディスクの両方を)変更する。
5. (A2)が(A1)のステートを調べ、再起動が必要か判断する。
#変更が大きい場合は再起動が必要になる場合・・・はあるが少ないだろう
6. (A2)に(A1)'のユーザーモードのステートを移行する。(内容によっては一瞬フリーズしたように見えるだろう
7. (A2)での実行を再開し、(A1)'は終了する。
この場合は、実質スムーズに移行できるはずです。
ご意見/ご指摘お願いします。 >>ALL&>>52>>30
なんのためにカーネル(A1)から(A2)に移行するのよ？
A1とA2の状態がまったく同じなら簡単に移行できるが、同じなら移行する意味が無いし、
違うのならメモリの内容も違うわけで、単純にメモリを移動しても動かないだろ。
それにカーネル上の一つのアプリを再起動すればいいだけの話じゃないのか。
これを実現するにはどうしてもアプリ側のサポートが必要不可欠。
OSを修正したからといってどうなるもんでもない。
たとえばアプリにデータ変更インターフェースを持たせる。
で、こうやって持たせれば、OSもマルチカーネルOS等というものも必要なく移行できる。
もちろんOSが移行するためにはOSにデータ変更インタフェースを持たせる
（これはOSのみ。OSがデータ変更インタフェースを持ったからといってその上で動く
アプリは別にデータ変更インタフェースを持たせないと移行できない）
つまり、OS(アプリ除く)を移行できるようにするならOSに、
アプリを移行できるようにするならアプリに、データ変更インタフェースを持たせれば十分。
マルチカーネルOSというものの出番はない。
必要なものがあるとしたら、それは単に一つのマシンでOSを複数動かすというエミュレータだけだ。
それはすでに存在しているし、時代はハードウェアサポートによるエミュレータ方式に移行しようとしている。
まずはやってみれ 色々馬鹿にしたような指摘の意味が判った後で何かしら社会に貢献し得る発見に至れるかもしれん
単にエミュレータを作るといえばなんの問題も無い。
その"エミュレータ"にOSを再起動せずに移動するなんて
エミュレータの仕事ではない実現不可能な機能をつけるのならそれは無理。
OSのアップデートを再起動なしに行う ･･･ OSの仕事。(OS内部のデータはOSしか知らないから)
アプリのアップデートを再起動なしに行う ･･･ アプリの仕事。(アプリ内部のデータはアプリしか知らないから)
エミュレータ(並列化)とアップデートを再起動なしに行うというのは
まったく別の話。分離して考える必要がある。
宇剤っていわれたら名無しに戻ります…
>>all(アプリ側の対応色々言ってる人)
（ユーザーランドの）アプリのアップデートではなく
あくまで今は（カーネルランド）のモジュールの再起動無しの更新な筈ですよ
（少なくとも初期のサンプルカーネルには二つのランドの切り分けは行わないでしょうが）
アプリがOSに再起動を要求することでしょうか？
その要求は破棄するしかないでしょう。
アプリには再起動したように返します。
アプリケーションの再起動(rebootではない)の廃止は
さすがに考えていません。
マルチカーネルの利点は「安定性」にもあるのです。
Aが処理中のとき、同じ機能を持つA'がそれを代わりに一時的行えば
安定性とRTが実現できます。
既にこれは多重化IOとして開発され実現されている物であり、
IOに限らずに全てのサービスに発展させた物と考えてください。
マルチカーネルが大規模開発されれば、
ユーザーサイドのリビルトができるようになります。
（設定変更に再起動の必要なし！）
つまり、各々のサービスはカーネルとして
独自に独立して走ることが出来るようになるので、
「専用OS」が実現できるのでは?と考えています。
(Web用OSやDVD書き込み用OSなど...)
専用OSはリソースをその動作のみに配当するので、
高速かつ安定かつ安全かつコストパホォーマンス高い状態で起動できます
時にリアルタイムOSとして時にデスクトップOSとして走ることが出来ます。
もしくは、機能を絞れば、
PDAや携帯電話にPCと同じOSを走らせるという、
現在の技術者の夢が叶うかもしれません！
＞某ドアフォ（小規模MMO）見たいに他人に迷惑掛け捲る訳ではなさそうですし
銀英伝？
> Aが処理中のとき、同じ機能を持つA'がそれを代わりに一時的行えば
> 安定性とRTが実現できます。
安定性とRTが実現できるという理由は？
ただのマルチスレッドでしょ。
> 独自に独立して走ることが出来るようになるので、
> 「専用OS」が実現できるのでは?と考えています。
> (Web用OSやDVD書き込み用OSなど...)
そんなもの作ってどうするの。
Web用OSとはWebアプリ、DVD書き込み用OSとはDVD書き込みアプリ
それを管理しているのがOS。
言葉遊びしているだけでしょ？
マルチカーネルがやろうとしている機能は
今OSがやっている機能に過ぎない。
一体何をしようとしているわけよ？
今何が出来なくて、何を解決するために、
どんな機能を作ろうとしているのかはっきり書きましょう。
言っているだけ。
リアルタイムOSと
Webアプリだけを入れたOSと
DVD書き込みアプリだけを入れたOSを
一つのマシンで動かすといっているだけ。
>>71
大枠では>>47と同じようなことを実施していると見てよいですか？
あと 仮カーネル(A1)'を起動して使用し､
> 4. (A1)を(A2)に(メモリとディスクの両方を)変更する。
とするのは
カーネル同士が「紳士協定」でほぼ固定的なアドレスにあり(A1)を(A2)に切り替えるためには
(A1)の保持している固定アドレスのメモリやディスク等の資源を解放する必要があるためと理解して
良いでしょうか？
（何かちがうような気が､、じゃ(A1)'の立場が､､､）
ここでの構造体>>48はカーネル(A1)(A2)の内部の構造体と考えて良いですか？
あと>>71の「ある程度の前提条件」は52さん(>>77）の
カーネルランドのモジュール構造には（例えばRTOSのOS-9みたいな）
きつめの制限を掛けてやれば､
結構カンタンに整えられそうですね
新鳥◆ArchEPGtMY
よろしくお願い致します
> ×マルチカーネルOS → ○エミュレータ
てことも無いでしょう｡ というかエミュレータ云々なんて､ずっと先の話じゃないでしょうか？
> エミュレータ(並列化)とアップデートを再起動なしに行うというのは
> まったく別の話。分離して考える必要がある。
分離して考えることにははある程度は賛成ですが､
これはマイクロカーネルの考えを拡張してやろうてな試みの一つですから
例えば カーネル再起動なしにデバイスドライバー（マイクロカーネルOSから
見れば一種のアプリ）等を差し替えたりできるOSと同様に､
ドライバー側を停止させずにカーネルをチェンジ出来る｡ ような柔軟性を
持たせておくのは色々と面白いことが考えられそう（具体的には思いついていないけど）
に思えるのですが､､､
RTOSのOS-9はもちろんシングルカーネルですが､ユーザーサイドのリビルドが出来､
ディスクドライバの設定やドライバ丸ごと差し替えをしても再起動は必要ありません｡
機能を絞った構成で組込みに多く使われ､ニッチにはGUIを持つデスクトップ機
もあるようです（専用機ですが）｡ つまり>>79 で仰る機能を装備したOSは既に色々ありますし､
マルチカーネルじゃなくても出来ます｡
今のところマルチカーネルの実際的メリットは､よくわかんないｗ､、でも良いのでは？
ドライバーを停止させずにカーネルをチェンジすることは可能。
現実問題ドライバーはカーネルの機能に依存しているので
ドライバーを停止させずにカーネルをチェンジすることは不可能。
複雑に考えすぎてましたね(^^;
現実問題あまり(A1)から(A1)'に移行することにはあまり意味はありません。
あるとすれば・・・
・(A1)から(A1)'に移行するときに必要に応じて「移行に適した環境」を整えられる(ほとんど意味がない)
・・・ぐらいですかね。おそらくもっと単純に(A1がアップデートしたA2を起動し、移行)実装できますorz
>>91
同期を用いることによって可能です。
その場合、すべてのドライバが移譲可能な状態になるまで
カーネルがwaitする、ということになると思います。
#それができない場合は再起動が必要ですけど…
もしカーネルの機能面での話を言っているのであれば、>>71の条件「下位互換性」でクリアしています。
>>84
もう少しシンプルに実装できることがわかったので、>>47とは違う方式でいけそうですｗ
再起動する必要性の消滅だけに限らないんですけどね(^-^)
この機能について皆さんが言及してくれると言うことは、
多くの人がこの機能を希っていると言うことでしょう。
開発意欲が湧きますよ。
一番大まかな方法は、
アップロードのシステム更新の一瞬を
以外にカーネルに処理が移らないようにすれば、
アプリケーションやミドルの打撃、データ構想の違いは
吸収できると考えますが...?
2005-2006年はOS業界激動のとして見受けました！
この激動の年に「マイクロカーネル」という
革新的思想の元、新技術が開発すれば、
Windowsを越す普及を得ることも出来るかもしれません！
---かなり興奮気味
再起動の定義はなんだ？
BIOSまで戻らなくてもOSの再起動はあり得る。
複数のOS環境を同時に稼働出来るのに高速？
最低でもディスパッチ分のオーバーヘッドは掛かる。
各サービスを入れ替えるのに再起動が不要？
Mach上でマルチサーバー構成でOSを構築すれば既に実現可能。
本当にリアルタイムOSが何であるか判って書いてるか？
携帯とPCで同じOSを走らせる意味は？
同じアプリが動くメリットなら既にJavaがある。
世の中のOSがWindowsだけで無い意味を知って、
その意味をもっと考えて欲しい。
ユーザーランドならカーネル止めるまでもなくソフトウェア側の機構一つで同にでもなる
のであんまり革新的な機構にならないと思いますが？
それからOS業界は激震というほどの物ではないでしょうね
ただ今年のうちにどれだけwindows離れが進むかには興味がありますが
それから一年のうちにまともなOSが出来ると思ったら大間違いですよ
特に複雑なAPIがいくつもあると0からの開発で2年以上は楽にかかりますから
（開発意欲なんて書いてるけどほんとにやった事あるのだろうか）
開発状況や結果概念は随時紹介することにします。
また、β版の公開はみなさんへの恩返しとして、
2chでなにより速報するつもりです。
御願いしたいことは、このスレッドをさないで下さい。
このスレッドの書き込みは資料としてまとめています。
参考にしていきますので、どうかご協力を。
ありがとうございます｡
> ・(A1)から(A1)'に移行するときに必要に応じて「移行に適した環境」を整えられる
なるほど､下のように理解すれば良いですか？
（用語を変えて､アップデート前のカーネルをA1,B1､アップデート後をA1,B2とします）
1. A,B間では少なくともプロセススケジューラなどは何らかの形でデータやり取りが必要
2. B2ではA1､B1で使用していなかった,或いは違う形式のデータやりとりが必要となるとする
3. すると､B1→B2アップデート時にはA1も一部の機能の「部分アップデート」が必要となる
4. そこで「A1部分アップデート」が済むまで（A1）'を起動し肩代わりさせる
ただ､仰るように逆に相互依存性が強くなりすぎる等､複雑すぎかも知れませんね(^^;
.-=・=- i､-=・=-
.. / ｰ-' ヽ . .
.. -=ﾆ=- お仕置きしてあげようかね？
.｀ﾆﾆ´
ちょいと理解できていないのですが、AとBはどの様な関係にあるのでしょうか？
頑張れ!
ありゃりゃ､良く見ると>>99は途中でA､Bを(>>71)のものから取り替えてしまって
ロジックが破綻してます｡ そうして見るとロジックでさえ無い orz
一応説明しますと､
・A,Bは同時に動いているマルチカーネルの2つのカーネルの各名称
・1,2の添字はそれぞれのバージョンみたいなもの
・で､この場合の移行は (B)が(B1)→(B2)、 (A)は(A1)→（A1一部改 = A2）
てな意味でした (続く）
もともと(>>92)
> ・(A1)から(A1)'に移行するときに必要に応じて「移行に適した環境」を整えられる
の「必要性」が「マルチカーネル故に」出てこないか考えた結果でして､
例えば (A1)が(A2)に替わるときに､もし協調機構が変わったら､(B1)も(B2)替えにゃ
いかんだろなあ、、
と考えただけでして､ロジックになってないし､意味も殆んどないです orz
・A-よく動く
・B-よく働く
↓
強調動作でビームとか出る
↓
明日はホームラン→むしろ野球嫌い→小池栄子はどうでもいい派？
↓
エスペラント
>>105で思いついたのが協調機構とかは(ある程度)ライブラリ化できないか…ってことなんですがｗ
あるいは「協調機構」を表す部分だけを自由に書き換えできる機構をつくるとか(^^;
あとは(A2)や(B2)に、(A1)や(B1)のための「環境を移行するためのルール(関数)」を作成するとか。
色々話が分からなくなってきてる…orz
architecture は？
マイクロカーネルにする以上、高速性はあきらめるべきだとおもわれ。
そのかわりに、安定化を強化して「高速に思える」ようにするべき。
数値的な効率よりも感覚的な効率の方が(･∀･)ｲｲ!
>>18=>>1 ?
えっと>>18さんは､（いまだ釣りの疑いが消えない）>>1氏じゃないですが､
たぶん少し前からここは>>18さんのスレ（になる予定？）です｡
>>106
まあ､ライブラリ化とか書き換え可能とかの私の妄想取り入れると､どんどん複雑に
なるので>>99や >>103-104みたいなのはバッサリ切捨て､ルールはバージョン替わっても
固定､ぐらいに､､､一旦置いときましょうよ｡
と､言いますか､そんな感じでお願いできませんでしょうか？m(_ _)m
また､あわてて書くと「トンでも・メカニズム」になりそうなので､ゆっくり考えてみます
p.s. 2-3日見れなくなりそうです
ライブラリを作ればいいってことか。
そしてそのライブラリを使ってインターフェースを実装した
アプリを作ってやっと対応すると。
うん。結局OS作ればそれだけで完了する問題じゃないんだよな。
とりあえず、二つのカーネルを起動するブートローダーを
開発しました。
仕組みは簡単。
ブートローダー１を起動
↓
ブートローダー１から
ブートローダー２を起動
↓
ブートローダー２がカーネル１を起動
ブートローダー２を開放
↓
ブートローダー１がカーネル２を起動
ブートローダー１を開放
なお、ブートローダー２はブートローダー１の
リソースを共有するので軽量。
切り替えコマンドでカーネルの切り替えに成功。
Xenと違うのかと思うんだが。
マルチCPU環境で各CPUで別のOSを起動させられるようにするとか、
そういう方面の方が嬉しいな。マルチコアCPUを活用しまくり。
このブートローダーからWindowsとLinuxを起動してみたところ
両方のOSがうまく起動しています。
どうやってハードウェアを共有しているのか不明ですが
なんとなく動いているようです。
公開お待ちしております。
カーネルなどはでok?
どうせブートローダーから動かした
カーネルって自作のカーネルで、
ハードウェアリソースはほぼ利用しない。
ただの小さなプログラム。
っていうのが関の山。
共有するためにドライバなどを組み込んで
ブートローダーがOS化するわけだなｗ
エミュレータでもなければカーネルがで動くわけが無い。
だったらまぎらわしい言い方しないで欲しいよね。
トリップつけれ(でないと偽者と本物の区別が(ある程度はつくけど)つかない
ネタ(?)の>>117にマジレスすると、両方の(修正なしの)OSは全リソースを使用することを前提にしてるから、
両方が同時に動こうとすると両方(あるいは片方)がコンフリクトで破壊されるのがオチ。
それが無いとすればただのエミュレータな訳だが。
そんな当たり前の話を偉そうにされても。。。
Xenの開発がんばってください。
http://219.56.24.98/
http://219.56.24.98/~ss.jpg
http://your-zgxj95zmlh/
http://your-zgxj95zmlh/~ss.jpg
どうせWindowsはなにもパワーアップしないんだろ？
じゃあいらね。
うはっｗｗｗおｋｗｗｗ？？
http://192.168.1.12/
http://192.168.1.12/~ss.jpg
http://Yama02.ITABS1.KN.HOME.NE.JP/
http://Yama02.ITABS1.KN.HOME.NE.JP/~ss.jpg
http://192.168.11.2/
http://192.168.11.2/~ss.jpg
http://computer2002/
http://computer2002/~ss.jpg
アセンブリ言語で簡単にスレッドって
実現できませんかね？
マルチカーネルで、
リソース管理とプロセス管理は
カーネル内プロセスで分離しますので、
（つまり、WindowsアプリやLinuxアプリ、専用アプリを
起動管理するカーネル内プロセスは別々で、しかし、
リソース管理は共有とします）
コンフリクトを避けるようにする予定です。
改正。
「>>18さん、>>117は偽者ですので。」
すみません。
だからそれは仮想マシン（エミュレータ）と言うの。
マルチカーネルなんて造語作るな。
TCP/IPでも使ってプロセス転送すりゃ住む話だろ。
カーネルレベルでやる話ではない。
http://jp.msnusers.com/NegishiK/page.msnw
ご意見御願いします。
ネタしつこい。
説明がemuとvmにしか見えないのはなぜでしょう？
普及済システム上に大型カーネルとは粋ですね
せっかくアップしてもらったけどOpenOffice-1.1.4ではレイアウトが崩れて読めません。
カーネル二つって、似たようなことをすでに考えて、
実装した人がいらっしゃるようなんですけど～
http://osask.jp/os_design.html
>必要ならカーネルが複数同時に動いていても一向にかまいません。
>OSASKでは、OSを終了させることなく、カーネルやデバイスドライバーを入れ替えることができます。これは、２つのカーネルを並行して走らせた状態にした後に、一方を終了することで完了します。
次はOSASKとの違いとメリットを示した、文書をキボンヌ
見てみましたが､私の能力では何が表現されているのかさっぱりわかりませんでした｡出来れば
ハードウエアリソースを土台にしたよくあるような図で書いて貰えませんか？
しかしその前に､、､そもそも他のOSの互換レイヤとかハードエミュレータとかはカーネルが
それなりの機能をもったしっかりしたものなら原理的には何の上ででも出来るだろうし､実装
方法も色々なバリエーションが可能でしょう｡ どうしてそんなカーネル上のOSサーバや
アプリに近いものの特徴・バリエーションがマルチカーネルの特徴になるんでしょうか？
>>143
そこから引用部をサーチして読むとOSASKでは カーネルとかシェルとかの用語の定義が
一般的なものとは結構違うみたいだし､その比較は妙な混乱を起こす元じゃないですかね？
実言うとマルチカーネルはOSASKのアーティキチャーを参考にしています。
（と言っても、既に考えていたときにOSASKを見つけたわけなのですが。）
OSASKでは、Shellをカーネルから独立させます。
しかし、カーネル自身はShellに依存するわけです。
マルチカーネルではそれぞれの依存関係を出来るだけ薄くするのです。
（それぞれのカーネルがそれだけで起動可能なぐらいに。）
ここに大きな違いがあります。
>>144これもまたご指摘ありがとう御座います。
はい、マルチカーネルの"機能"としてアップロードした文章の記載した内容は
マルチカーネルアーティキチャーによる"副産物"と言えるでしょう。
本来は、安定性や利便性、更新の簡易,簡便性、拡張性、移植性かつ"可変性"を向上するのが目的です。
>カーネル上のOSサーバーやアプリ
この言葉、的確にマルチカーネルを表していると思えます。
これからマルチカーネルのことをNetKernelと呼んでみてはどうでしょう？
>144さんの危惧が現実に…
自分用語作ってー支店じゃネーぞ
誰も興味盛ってねーんだから、さげろ。
トリップまでつけて、「age、アーティキチャー、いきなり動いた」、、、念のいった釣りだな
>>145
OSASKはどうか知らんがカーネルがそれだけで起動できるのは当たり前じゃねぇか
何かサンプル出来て公開されるとしたら、コピーライト表記とか気をつけて下さいね
どうも>>1氏の発言みてると技術以外にも周りのレスに乗っかって
「それは先に自分が考えてた」とちょくちょく言ってる点が気になる。
まあ先に>>147のコードが出て来て>>1氏の主張する機能が実装されてれば
これは私の下衆の勘ぐりと言う事になりますけどね。
>>152さん、>>153さん
全くその通りです。
自分が少し考え始めていたことを、
周りの人が話し合っていると、
つい「自分が考えていた」と言いたくなりませんか？
・・・いい訳ですね。m(_ _)m
反省します。。。
ｗうはっｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗうぇｗｗｗうはっｗｗｗおｋｗｗｗ
ｗｗｗｗｗｗ
おｋｗｗｗっｗｗｗｗｗｗｗｗｗｗｗｗ
全く独立したカーネルを沢山走らすのは、
メモリを消費するので、
カーネルをdllの「ようなもの」で構成してはどうでしょうか？
カーネルのプロセスはこの動的ライブラリを参照する機能だけ持っており、
実際の処理はライブラリ内で行われます。
こうすれば、複数のカーネルプロセスがこの動的ライブラリを参照できるはずで、
メモリ消費を抑えられるはずです。
考えた新しい構成
カーネルA,B,Cを作成する
通常はAが処理を行う
BはAが異常事態に陥ってないか常に確認する
Aが異常事態に陥っている場合は、BはAの代わりをする
CはBが処理を行っているか常に確認する
Bが処理を行っている場合は、Aを回復させ、Bの処理をAに渡す。
・・・どうでしょう？
Cのﾘｶﾊﾞﾘはどぉするね
Solaris10のZoneみたいなやつ？
このスレ終了。
実際はソフトよりもハード的な原因のほうが多いわけで。
だいたいソフト側が原因で不安定になるカーネルなんてWin9x並みだし使えない。
安定させたかったら始めからワークステーション名目で売られてるマシン買うし
いまは、二人目
頑張ってくれ
ひょっとして本当に >>1 が本気だったとしても、
ﾈﾀかﾏｼﾞか判断に何年も掛かりそうだな。
見てる側としては、カメラで開発している最中の写真とかうｐしてくれた方が、
より真実味を帯びてくると思うんだが
ttp://www.amazingty.com/images/dnotytt0034.jpg
ttp://www.dennio.com/tgp/phole2/amtpeehole0003.JPG
タイ━━━━||Φ|(|´|Д|`|)|Φ||━━━━ホ
まずは理想を全て捨て、只普通のOSを作ってみるべきでしょう。
それからマルチカーネルだろうが、好きにしましょう。
ってか普通のOSを作れない人が、マルチカーネルなOSを作れません。
普通のOSを製作しているMonaプロジェクトがどれだけ時間が掛かっているかを
考えましょうね。
考えることはサルでも出来る。その程度の思想は考えつくされてきているはずである。
なのに現実に全く出て来ていないのは、みんなの技量の問題ではなく、
成果が出ないことの表れである。
まぁ考えること、ガムシャラに頑張ることは悪いことではない。
それをのちのちに有益な財産としてくれれば。
Linux API もついてるし....
ｲﾀｿｰ
2個のタスクをリアルに同時実行させるなら、2個のPCを合体させてやりゃいい。
割り込みとかはOSの専権事項であるわけで、Winとかも自分勝手に使えると思ってる。
マルチにOSを走らせた場合は、タイマー割り込みとかはどう調停されるんだろう。
片方のOSが無効化しているときはもう片方のOSに割り込みが届かなくなってしまう？
結局>>1はタスクスイッチが"できる"ものと考えてOSを作っているが、タスクスイッチはOSが"する"もの。
アイディアのスタートする立ち位置がすでにOSではなくアプリケーションなのが最大の間違いだな。
ｸﾏ
>>167 >>168 >>171
怖くて見れねーよ。一体何の画像なんだ？
こんなにしたら、どっち使ってるか分かんなくなっちゃうじゃないか！
ってか、これじゃぁ、リークしまくりにならんのか？
/[へへ
、、。。。いいうええごさししすすせせそたつつつつてててでにににののははままもよらりるるれ
ををををををアィイオカカカキクチッテドネネネバヘマメモャリルルルローーーーーーー一二低
共同実展意抑持時有発考行見速
>>70
・モノシリックカーネル（Unix、Linux系）
・マイクロカーネル（Minix,Mona）
・ハイブリッドカーネル（Mac OSX）
こんなもんか？Windowsはどうなってんだろ？
>>1のマルチカーネル云々はどうでもいいんだが
次世代カーネルみたいな研究ってされているのかな？
つ ttp://wiki.osdev.info/?JP-OS
VMMってしらねーの？
今後メインのカーネルをハードウェアないし、マイクロコード等で実装するような動向はないのですか？？
それこそ脱x86みたいな
なぜかというと低水準な機能をハードウェアで剥き出しで実装して、あとはコンパイラに
任せる、というRISC流の方法であれば、ソフトウェアの柔軟性のご利益があるわけだが、
そこをマイクロコードでハードウェア化しちゃうと、ちょっとした性能向上とひきかえに、
柔軟性がなくなってしまう。「柔らかいハードウェア」も研究されたことはあるが望み薄
（と俺は見ている）。
そういう高水準の機能をワイヤードロジックで実装しようってのは正気じゃないでしょう。
複雑過ぎる。
RISCがベストならx86はどうなんだという話になるけど、x86は結局、過去の遺産の継承の
ベネフィットと利益率が高くかつ大量生産（数だけで言えば組込みRISCも結構行くが）
という規模の利益が、技術的な議論を凌駕しちゃってる。
今後ハードウェア化する意味のあるのは、特に並列化がらみでソフトウェアでの実装が
面倒な並行・並列処理のプリミティブとかぐらいじゃないかな、と（GPUとかを別にすると）。
あとはIBMのAS/400みたいな方向性だろうけど、あのレベルの仮想化はハードウェアで
実装するより、JavaVMとか.NETのCILとかLLVMのようなソフトウェアのレイヤで実現する
ほうが現実的だと思うね。
sun1 だったかsun2 だったか、68000 の片割れがこけると、もう一方が叩き起こしていた、らしい。
ありがとうございます
あーその伝説は微妙にウソ。
ttp://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html
ここに詳しく書いてあるが、初代68000はページフォールトを起こした時に、
コンテキストを保存してページを入れ替えて再開、ということができなかったので、
フォールトを起こしたらプロセッサを止めて、別のプロセッサがページを入れ替え、
入れ替えが済んだら元のプロセッサの実行を再開、ということをやったマシンが
あった、という話。
伝説でしたか。
でもこのトリックは、ページング関連ではなくてスーパーバイザ命令の割り込み関連の問題の回避のため、ときいているのですが。
そうでなければデバイスドライバに偽装するのが現実的？
例えば新しいデバイスに対応したOSaと古いデバイスに対応したOSbがあって、
両方サポートしたOSがない場合、ダミードライバが呼ばれた時に相手のOSにスイッチして、
その本物のドライバに仕事させて、それをダミードライバにトンネリングする。
つまり、適当なタイミングないしサポート外のデバイス（ダミードライバ）が呼ばれたら
相手のOSにスイッチするようにすることで、
個々のデバイスの詳細を知らなくてもそれぞれのOSドライバの作り方さえ知っていれば、
事実上デバイスフルサポートのOSが手に入ることになって、
これって考えてみるとおいしい話じゃないだろうか？なんか落とし穴あるかな？
リアルタイムカーネル化とか言ってた奴の場合はどうなの？