マルチカーネルOS開発中...
実行してしまうアーティキチャを考えています。
それらのカーネルは一つの共有メモリーを持たせて、
オーバーヘッドによる低速を抑えるつもりです。
ご意見を。
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､-=・=-
.. / ｰ-' ヽ . .
.. -=ﾆ=- お仕置きしてあげようかね？
.｀ﾆﾆ´
100～のスレッドの続きを読む