マルチカーネルOS開発中...

マイクロカーネルを発展させ、ついにはカーネルを二つ同時に
実行してしまうアーティキチャを考えています。
それらのカーネルは一つの共有メモリーを持たせて、
オーバーヘッドによる低速を抑えるつもりです。
ご意見を。

!i.　　　　　　　　　　　　　　　　 i,　　　　　 !　なんと！ 明治天皇陛下が>>2getなされました！
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 新平 　 大久保ごときに惨敗すんなんて、お前ホント雑魚だな（笑

それ、普通に仮想化してるだけじゃないの？

マルチがカーネルのOSほしい。

HTですた、というｵﾁ

>>1
もっと詳しく､具体的に

ええけつしとるのぉ(*´Д`)ﾊｧﾊｧ
http://219.173.171.38/
http://219.173.171.38/~ss.jpg
http://your-kmiajdwmaj/
http://your-kmiajdwmaj/~ss.jpg

カーネルサンダース。

>>1
要するにVMWare ESX Serverみたいな物？

1です。
MicroKernelアーティキチャのもと、
分離されたカーネルの機能を各ミドルウェアに実装します。
つまり、「カーネルが複数存在する」または
「カーネル(全体制御中枢)が存在しない」と表現できます。
MicroKernelといってもMachから派生するわけではありません。
仕様は複雑難解になりますが、革新的なアーティキチャになると確信しています。
☆考えられる利点☆
１．もし、Windowsのカーネル(当然このOS用にビルトしたもの)を
このOSで実行できれば、エミュレーターの数十倍ものスピードで
Windows専用のアプリケーションが実行できます。
２．中心が存在しないことは
「どの一点が停止しても全てのサービスが停止することはない」を意味します。
つまり、Linuxより協力なサーバーとして利用できます。
並列処理が強化されるので、OSは安定するはずです。
セキュリティーシステム等も強化できます。

http://www.amazon.co.jp/exec/obidos/ASIN/4569620973/250-1363011-4885857

>>10
要するにマシンを二台置けばいいってことだな？

(･∀･)ｱｰﾃｨｷﾁｬ!
(･∀･)ｱｰﾃｨｷﾁｬ!
(･∀･)ﾋﾞﾙﾄ!

で、その複数存在するカーネルは誰が統制すんねや。
カーネルか？

ﾓﾅｰＯＳつくるような根気が>>1にあるかどうか

>>14
出来るだけなんとか頑張ってみます。
>>13
統制する物はありません。
カーネルからカネールへのシステムコールをもサポートします。
データは共有メモリによって最速化します。
（共有メモリは一つ）
>>12
一台で、一つのCPUで起動します。

>>1
そんなもんいらない。

http://pc.watch.impress.co.jp/docs/2005/0330/amd.htm

　Pacificaは、CPUのリソースを独立したパーティションとして分割し、
その分割した各リソース上で複数のOS/アプリケーションを
動作可能な仮想化技術。単一のシステムが複数の“仮想システム”として
動作する。Pacificaのパートナー企業は、Microsoft、VMware、
XenSourceらが名を連ねる。

え　ぇ　け　っ　し　と　る　の　ぉ(*´Д`)ﾊｧﾊｧ


うはっｗｗｗおｋｗｗｗうえっうえっｗｗｗ？？

>>16
観点からして違うだろ(藁

>>1
複数の「仮想カーネル」を統べるカーネルが存在しないってことだけど、
それだとメモリ管理とかはどうやってやるんだ？

画期的なアーティキチャのカーネルをビルトする。

ちょっとおまいさん、
アーティキチャって何か教えてくれんかのう。

結構みんな そこそこ(半)マジレスしてるけどさ　(>>5 >>9 >>13 >>16 >>18)
それに まともに答えようとするそぶりはないし
特に>>10の　☆考えられる利点☆　の後読めば

要するにネタじゃん 　　って､折れも釣られた事になるなｗ

えーPCから離れていました。
>>21ネタではありません。
しかし、完成できなかったり、実用化されなかったりしたときは
結局ネタになってしまうのかもしれませんね。

>>18アプリケーションのメモリ管理は専用のカーネルを作成します。
カーネル内でのメモリ管理は相互に監視、管理していきます。

ふーんネタじゃないのか　じゃ教えて欲しい｡　下の１．２．３．は折れの貧しい
知識で考えると矛盾するんだが､

１．> 「どの一点が停止しても全てのサービスが停止することはない」(>>10)

２．>　一台で、一つのCPUで起動します。(>>15)

３．>　統制する物はありません。(>>15)

2つのカーネルをA,Bとすると　１．には�@A,Bの切り替え　�AA,B相互のメモリ保護､が最低必要だけ
ど統制する親カーネルなし　VMでも マルチCPUでも 複数マシンでも無しに､どうやって実現するの？

今までの色んなヒトの質問を少し具体的にしただけだけど､

流れ読めよ。既にスレタイは関係ない。

ここは画期的なｱｰｷﾃｨﾁｬのスレだぞ？

失礼、アーティキチャだったな
画期的なアーティキチャがあれば何でもできる
そんな風に考えていた時代が僕にもありました

だからこれでいいじゃん。
これじゃいけない理由書いてよ。

http://pc.watch.impress.co.jp/docs/2005/0330/amd.htm

　Pacificaは、CPUのリソースを独立したパーティションとして分割し、
その分割した各リソース上で複数のOS/アプリケーションを
動作可能な仮想化技術。単一のシステムが複数の“仮想システム”として
動作する。Pacificaのパートナー企業は、Microsoft、VMware、
XenSourceらが名を連ねる。

日立のDARMA?

ちょっとだけ期待sage

>>26
要するにPacificaの「拡張」でもあるし「原始的」な部分もある。
>>1の言ってる部分で共有メモリを用いる点では複数のカーネルを動かすのに適してる。
ただしCPUを完全に(Pacificaのようには)分割してないから「独自ビルドのカーネル」が必要。

その意味合いで「観点が違う」と言ったんだが。

>>1
例えば通常のOSではハードウェア制御のドライバがある(Windows NTではカーネルモードで動作する)訳だけど、
そのコンフリクトその他の制御はどうやってやるの？
# x86だったら単純にできそうな気もするが……

>>1はだんまりなのか考え中らしいので　ちょっと考えてみた

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

ついでに（>>10)の

> ☆考えられる利点☆
> １．もし、Windowsのカーネル(当然このOS用にビルトしたもの)を
> このOSで実行できれば、エミュレーターの数十倍ものスピードで
> Windows専用のアプリケーションが実行できます。

は､「当然このOS用にビルトしたもの」だったら
カーネルがマルチかどうかはカンケーないんじゃない？つまり

○MkLinuxは､BocksやQEMU上で動かしたLinuxより速いです
○Debian GNU/Linux と　Debian GNU/NetBSDは同じぐらいの速度です
○MacOSXはFreeBSDに対して速度的に遜色ありません

と同じことを言ってるように折れには見えるが？

いっぺん上げ

23さん本当にありがとうございます。
上の違いは「Windows」互換のカーネルが独立して走る所です。
>>30
私の考えているものは全くそれです。
>>31
利用ですが、
青画面にあることを防ぐこと以外にも
Updateの利便性向上です。
WindowsではUpdateを行ったとき、
再起動を行う必要がある場合が多いですが、
これが不必要になります。
(再起動と言う言葉自体消えるかもしれません。)
また、重要システムの根本的グレードアップ
(WinMe → WinXpのような)
も、再起動が不必要になるかもしれません。

私はまだ、かなり未熟のようです...
PacificaやDARMAなどを全く知りませんでした...
教えていただきありがとうです。
ここでも書き込みは「要求」として
資料にまとめていっていますので、
ご意見どうかよろしく御願いいたします。

ヽ（`Д´）ﾉ ｳﾜｧｧｧﾝ やっぱ釣りじゃねえか
何でこんないい加減なモノ（>>30-32)にボロクソ突込みじゃなく「ありがとう」なんだよ（・∀・）ｶｴﾙ!!

> WindowsではUpdateを行ったとき、
> 再起動を行う必要がある場合が多いですが、
> これが不必要になります。

正確にはパソコンを再起動する必要が無くて、
OSだけの再起動ですむということです。

もちろんOSの再起動時にはそのOSで
動いているサービスはすべて一旦停止します。

のうがきいいからさっさとβ版つくりはじめろよ。
モナーでもわかるように基礎だけでも２、３年かかっとるんだから
つくってなんぼだよ

Windowsカーネルをカスタマイズしないと使い物にならない時点で絵に描いた餅じゃね？

>>36
結局再起動してるじゃん。
意味ねーｗ

再起動するのは一部のシステムであり、
全てのサービスを停止する必要はありません。
また、AとBが同じ動作をサポートするようにします。
つまり、Aが再起動中にBがAの代用をし、
Aが正常に起動すれば、Bを再起動するようにするのです。
こうすれば、ユーザーやアプリケーションから見れば、
再起動していないように見えます。

>>36は偽者です...
ヽ（`Д´）ﾉ ｳﾜｧｧｧﾝ
>>40がホンモノ...僕です。

気付けば、僕が考えているアーティキチャを
説明するスレッドになってしまっていました。
ここでは僕が考えているアーティキチャについて
意見と要求を書き込んでいただきたいのです。

>>1
取り合えずトリップつけてくれ

それからメモリの紳士協定の具体的な実装はどうするつもり？
一応2個以上のカーネルを動かすのだろう
2つのカーネル間での調停用の通信機能を持たせるのか？

カーネルおよびPSの起動時は特殊なブートローダーでも使うの？
プロセスをカーネル間で移動させるってのは実現可能でもうlinuxとかで出来てるけどな

少なくとも革新的過ぎて着いていけない

トリップって名前の最初に#を入れるやつですよね？

BIOSは一つのカーネルしかブートできないはずなので、
BIOSから「第一のカーネル」がブートされます。
この第一のカーネルによって
他のカーネルは起動されるわけですが、
このとき、紳士協定としてメモリは配分されるようにします。

しかし、この方法だと、
他のカーネルは「第一のカーネル」によって
管理されるわけではないので、配当を増やすことは出来ません...
まだ考案中です(ﾟ∀ﾟ)

>>1
　調停を「カーネル」だけで行うのには無理がある。
なぜなら、
　・メモリの無駄
　・対障害性が不十分
の面がで不都合が生じるから。
　そうなると(機能を最小限に抑えた)「親カーネル」が必要だね。

　個人的にはカーネルＡとカーネルＢが(ある程度、障害が起きた時以外でも)
協調できると良いと思う。

　それではﾉｼ

45を書いてる間に44ができてたらしいので、追記。

>>1
　>>44で書かれたように、初めにメモリを(固定的に)割り当てると、それこそESXと変わらないわけで(^^;
　>>45で書いたような仕組みにして、動的に(おおまかでもいいから親カーネルが)メモリを割り当てた方が良い気がする。

>>40
矛盾している。

> 再起動するのは一部のシステムであり、

> つまり、Aが再起動中にBがAの代用をし、
> Aが正常に起動すれば、Bを再起動するようにするのです。

再起動するのは一部のシステムじゃなかったのか。
ようするにOSを二つ同時に起動しておいて
本システムをアップデートする前に副システムに切り替え
本システムをアップデートして元に戻すってことだろ。
たんなる多重化じゃん。

アップデートが必要なサービスがある。

アップデート前にそのサービスのメモリ内に次のような構造体のデータがある。
struct FOO {
char a;
char b;
}

これがアップデート後に次のような構造体に修正される。
struct FOO {
long a;
long b;
}

>>1
さて、どうやって再起動なしに処理を続ける？

>>47
　システム＝コンピュータ全体
　システムの一部＝複数あるカーネルの内の一つ

と(俺は)解釈したんだが……(^^;
合ってる？>>1

ようするにエミュレータで複数のOSを
動かしているのとなんの違いも無い。

マルチカーネルOSなどといっているが
エミュレータそのものである。

>>48の問題は(他の問題がありながらも)解けたが、
>>1のために(ryしとくわ(^^;

>>44
BIOSからブートローダーを読み出して2つのカーネルとPSが立ち上がるまで管理するんじゃないの
それ以降は2つのカーネル間で調停なり協定なりでメモリを配分させるんじゃない？

BIOSとブートローダー（一般的には）は違う物だよ

>>51
OS(Windows)の対応だけじゃ無理だね。
この例ではメモリのアドレスをずらすだけで可能だけど、
もしかしたらまったく違うデータ構造になるかもしれない。
これに対応するにはOSの対応とは別にアプリ自体にデータ変更機能をつけるしかない。

バックグラウンドで再起動して
ユーザーに再起動をしていないように見せかけるには、

Windows等のOSが再起動しても・・・の場合は、Windows等OSを修正すればいい。
アプリケーションが再起動しても・・・の場合は、アプリケーションを修正すればいい。

よって、マルチカーネルOSなどと言うものを作る必要は無い。
それともWindowsとはまったく別のOSを作るという話か？

>>1は用語の定義をしろ。
システムが何でサービスが何で、
どれを再起動するのかとか全然わけわからん。

>>47
　文をしっかり読んでなかった、スマソorz

>>52
　説明不足だった。調停とかを親カーネルなしですると
(複数カーネルの中で)同じようなコードが重複したり、(調停ルーチンの)変更が難しかったり、
調停ルーチンが間違っていたりバージョンが違ったりすると全体が落ちる可能性があったりするから
調停ルーチンを抽象化する「親カーネル」を持った方が良いのでは、と思ったわけ。

>>53
　ライブラリとかの変更だと俺の解法だと無理なわけでorz

>>18
ありがと､なんか「らしく」なって来たよー

>>1
勝手に仕切るようで悪いが 頻繁にWindowsの利便性と較べる話をしてるが､
そういうのはこのOSがLinux ver.1?ぐらいになって
「Wineを載せるか､いやReactOSから､、」ぐらいになってから考えてくれない？
アナタの考えるべきは､まずマルチカーネルを成立させることでしょ｡

で､まるちかーねる､の長所としてまず確立すべきは耐障害性じゃね？>>All

そんで､まあ(>>30アーティキチャ？）で行くなら別に良いけど､このままじゃ成立しない
或いは複雑になりすぎて逆に耐障害性は落ちる等､色々指摘されてるし､
一番まっとう「普通の」解決方法は「親カーネル」､､､でもこれじゃ>>6に逆戻りっぽいし､､､

と､すると>>1さん､アナタの示すべきはこれら問題の「画期的かつシンプル」な
解決方法じゃない？　
ホントにコロンブス卵がなければ､例えば天才の閃きで「バッサリ割り切る」でも良いかも
C言語とかUNIXとかも何かそんなとこもあるし､､､


なんか偉そうにすみません>>1 & >>ALL

>>18氏
個人的にはそれだとxenと同じで面白くないと思ったのですよ

基本的にはGRUBのようなものを起動完了まで親カーネルの役割をさせておいて
起動してから自分自身をアンロードするというものです
その後はカーネル間で調停を行っていく（この中でどちらかに調停用のプロセスを走らせて
親カーネルの役割をさせていく必要があるかもしれませんが）

それから構造体の変更については難しいですがなんとか変更できるのでそういうのをやったらどうでしょうか
（つーかシステムの基幹にかかわるようなサービスは両カーネルで走らせて置いてアップデートの時には片方を
アップデートしつつもう一方のサービスのプロセスをコピーさせてもらうとかまだ方法は幾つかあると思いますが
どちらにせよプロセス間通信などをいままで以上に複雑化しなきゃいけない…）

>>59
ごもっともですね。(少し口調変更
xenという物を(界隈に居ながら)知らなかったのでorz

おかげで別のアイデアも思い付いて来ましたし…ｗ

>>59
だからバックグラウンドでアップデートするのは簡単なんだよ。
問題は古いプロセスを使っている状態から新しいプロセスに移行する方法。
これはデータ構造が違う可能性があるので、走らせたままで移行するのはアプリ自身が
対応しない限り不可能。以前のバージョンでは存在しなかったデータが作られる場合だってある。
だからOSの変更やマルチカーネルOSとかの対応だけじゃ無理。
プロセス間通信を強化しても無理。内部データの変更はアプリ自身でしか知ることが出来ない。
逆にアプリ自身が対応するのなら、OSの変更やマルチカーネルOSなどなくても可能。

> で､まるちかーねる､の長所としてまず確立すべきは耐障害性じゃね？>>All
同一のハードウェア上で起動している以上
ハードウェアが壊れたときの耐障害性は期待できない。
また同一のOSが二つ起動していたとして、一つだけがソフトウェア的に
おかしくなることはありえない。
また再起動なしでアップデートとかもデータ構造の違いがあるために非現実的。

期待できるのは、独立した複数のOSを同時に起動できるという
今世間がハードウェアでやろうとしていることの遅いソフトウェア版ということだけ。
そのソフトウェア版もすでにVMWAREが実現している。

何つーか否定的ですねぇ…
別にこれを売ろうとかしている訳じゃなくあくまで趣味しかもまだ企画段階であって
これからどんな風になるか解からんし

某ドアフォ（小規模MMO）見たいに他人に迷惑掛け捲る訳ではなさそうですし

まぁ本音はこの楽しそうなおもちゃを取られたくない
見たいなものですかね

非常に知的興味心を満足させてくれるような企画なんで（仮想化技術のそれぞれのアプローチ自体がですよ）

>>62
>一つだけがソフトウェア的に…
同じＯＳが同じ時間に同じ処理をやるのなら有り得るけど、そういう状況にはどうしてもならないから、
微妙な違いで一つだけがハングすることは十分有り得ます。

>>63
　期待してますｗ　(サンプルでも実装してみようかな

ちなみに私はニーモニックなんて出来ませんよ
そのため実装できませんｗ

つーかMONAをサンプルに借りればいいのかな？

あ、結構monaではきついかもしれませんね
実際かなりの量のAPIの追加も必要になるし

>>66
　サンプルにMonaは敷居が高い(^^;
　とりあえず、一からコード(2種類の「カーネル」＋「補助カーネル」)を組んでみます。

ただ手元にPCがないから書くのは明日以降かな。

>>18 さん　（＆52さん）　期待してます｡　

そろそろ付いていけなくなりそうな雰囲気なので(^^;
（>>51（>>1のために(ryしとくわ(^^;））
みたいなこと言わずに色々公開してオベンキョネタを下さい

完成予定は3015年ですm( __ __ )m

なんとなく(眠ってた)トリップをつけてみました。

>>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

>>71
なんのためにカーネル(A1)から(A2)に移行するのよ？
A1とA2の状態がまったく同じなら簡単に移行できるが、同じなら移行する意味が無いし、
違うのならメモリの内容も違うわけで、単純にメモリを移動しても動かないだろ。
それにカーネル上の一つのアプリを再起動すればいいだけの話じゃないのか。

だいたい、マルチカーネルOSにする理由がわからん。
これを実現するにはどうしてもアプリ側のサポートが必要不可欠。
OSを修正したからといってどうなるもんでもない。

たとえばアプリにデータ変更インターフェースを持たせる。
で、こうやって持たせれば、OSもマルチカーネル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を走らせるという、
現在の技術者の夢が叶うかもしれません！

>>63
＞某ドアフォ（小規模MMO）見たいに他人に迷惑掛け捲る訳ではなさそうですし
銀英伝？

>>79
> Aが処理中のとき、同じ機能を持つA'がそれを代わりに一時的行えば
> 安定性とRTが実現できます。
安定性とRTが実現できるという理由は？
ただのマルチスレッドでしょ。

> 独自に独立して走ることが出来るようになるので、
> 「専用OS」が実現できるのでは?と考えています。
> (Web用OSやDVD書き込み用OSなど...)
そんなもの作ってどうするの。
Web用OSとはWebアプリ、DVD書き込み用OSとはDVD書き込みアプリ
それを管理しているのがOS。

言葉遊びしているだけでしょ？
マルチカーネルがやろうとしている機能は
今OSがやっている機能に過ぎない。

一体何をしようとしているわけよ？
今何が出来なくて、何を解決するために、
どんな機能を作ろうとしているのかはっきり書きましょう。

>>1はエミュレータで複数のOSを動かすと
言っているだけ。

>>1はエミュレータを使って
リアルタイムOSと
Webアプリだけを入れたOSと
DVD書き込みアプリだけを入れたOSを
一つのマシンで動かすといっているだけ。

おこがましくもトリップつけてみました
>>71
大枠では>>47と同じようなことを実施していると見てよいですか？

あと　仮カーネル(A1)'を起動して使用し､
>　4. (A1)を(A2)に(メモリとディスクの両方を)変更する。
とするのは

カーネル同士が「紳士協定」でほぼ固定的なアドレスにあり(A1)を(A2)に切り替えるためには
(A1)の保持している固定アドレスのメモリやディスク等の資源を解放する必要があるためと理解して
良いでしょうか？

（何かちがうような気が､、じゃ(A1)'の立場が､､､）

ここでの構造体>>48はカーネル(A1)(A2)の内部の構造体と考えて良いですか？

>>18 さん

あと>>71の「ある程度の前提条件」は52さん(>>77）の
カーネルランドのモジュール構造には（例えばRTOSのOS-9みたいな）
きつめの制限を掛けてやれば､
結構カンタンに整えられそうですね

即行でとり変更です

新鳥◆ArchEPGtMY
よろしくお願い致します

>>75-76
>　×マルチカーネルOS → ○エミュレータ
てことも無いでしょう｡　というかエミュレータ云々なんて､ずっと先の話じゃないでしょうか？

> エミュレータ(並列化)とアップデートを再起動なしに行うというのは
> まったく別の話。分離して考える必要がある。

分離して考えることにははある程度は賛成ですが､

これはマイクロカーネルの考えを拡張してやろうてな試みの一つですから
例えば　カーネル再起動なしにデバイスドライバー（マイクロカーネルOSから
見れば一種のアプリ）等を差し替えたりできるOSと同様に､

ドライバー側を停止させずにカーネルをチェンジ出来る｡　ような柔軟性を
持たせておくのは色々と面白いことが考えられそう（具体的には思いついていないけど）
に思えるのですが､､､

よいしょっと

>>79　（トリップついてないですが>>1さんですか？）
RTOSのOS-9はもちろんシングルカーネルですが､ユーザーサイドのリビルドが出来､
ディスクドライバの設定やドライバ丸ごと差し替えをしても再起動は必要ありません｡

機能を絞った構成で組込みに多く使われ､ニッチにはGUIを持つデスクトップ機
もあるようです（専用機ですが）｡　つまり>>79 で仰る機能を装備したOSは既に色々ありますし､
マルチカーネルじゃなくても出来ます｡　

今のところマルチカーネルの実際的メリットは､よくわかんないｗ､、でも良いのでは？

でなに？ 新しいOSを作りたいの？

ドライバーがカーネルの機能を使わなければ
ドライバーを停止させずにカーネルをチェンジすることは可能。

現実問題ドライバーはカーネルの機能に依存しているので
ドライバーを停止させずにカーネルをチェンジすることは不可能。

>>84 (>>30さん)
　複雑に考えすぎてましたね(^^;
　現実問題あまり(A1)から(A1)'に移行することにはあまり意味はありません。
　あるとすれば・・・
　　・(A1)から(A1)'に移行するときに必要に応じて「移行に適した環境」を整えられる(ほとんど意味がない)
　・・・ぐらいですかね。おそらくもっと単純に(A1がアップデートしたA2を起動し、移行)実装できますorz

書き忘れorz

>>91
　同期を用いることによって可能です。
　その場合、すべてのドライバが移譲可能な状態になるまで
　カーネルがwaitする、ということになると思います。
#それができない場合は再起動が必要ですけど…
　もしカーネルの機能面での話を言っているのであれば、>>71の条件「下位互換性」でクリアしています。

>>84
　もう少しシンプルに実装できることがわかったので、>>47とは違う方式でいけそうですｗ

マルチカーネルを実装する理由は、
再起動する必要性の消滅だけに限らないんですけどね(^-^)
この機能について皆さんが言及してくれると言うことは、
多くの人がこの機能を希っていると言うことでしょう。
開発意欲が湧きますよ。

一番大まかな方法は、
アップロードのシステム更新の一瞬を
以外にカーネルに処理が移らないようにすれば、
アプリケーションやミドルの打撃、データ構想の違いは
吸収できると考えますが...?

MacromediaがAdobeに買収されたんですね!?
2005-2006年はOS業界激動のとして見受けました！
この激動の年に「マイクロカーネル」という
革新的思想の元、新技術が開発すれば、
Windowsを越す普及を得ることも出来るかもしれません！
---かなり興奮気味

何度聞いても、「カーネル」の言葉遊びにしか聞こえない。

再起動の定義はなんだ？
BIOSまで戻らなくてもOSの再起動はあり得る。

複数のOS環境を同時に稼働出来るのに高速？
最低でもディスパッチ分のオーバーヘッドは掛かる。

各サービスを入れ替えるのに再起動が不要？
Mach上でマルチサーバー構成でOSを構築すれば既に実現可能。

本当にリアルタイムOSが何であるか判って書いてるか？
携帯とPCで同じOSを走らせる意味は？
同じアプリが動くメリットなら既にJavaがある。

世の中のOSがWindowsだけで無い意味を知って、
その意味をもっと考えて欲しい。

>>94、95
ユーザーランドならカーネル止めるまでもなくソフトウェア側の機構一つで同にでもなる
のであんまり革新的な機構にならないと思いますが？

それからOS業界は激震というほどの物ではないでしょうね
ただ今年のうちにどれだけwindows離れが進むかには興味がありますが

それから一年のうちにまともなOSが出来ると思ったら大間違いですよ
特に複雑なAPIがいくつもあると0からの開発で2年以上は楽にかかりますから
（開発意欲なんて書いてるけどほんとにやった事あるのだろうか）

･･･とりあえず、開発に徹することにします。
開発状況や結果概念は随時紹介することにします。
また、β版の公開はみなさんへの恩返しとして、
2chでなにより速報するつもりです。

御願いしたいことは、このスレッドを殺さないで下さい。
このスレッドの書き込みは資料としてまとめています。
参考にしていきますので、どうかご協力を。

>>92 (>>18さん）
ありがとうございます｡　
> ・(A1)から(A1)'に移行するときに必要に応じて「移行に適した環境」を整えられる　

なるほど､下のように理解すれば良いですか？
（用語を変えて､アップデート前のカーネルをA1,B1､アップデート後をA1,B2とします）

1. A,B間では少なくともプロセススケジューラなどは何らかの形でデータやり取りが必要
2. B2ではA1､B1で使用していなかった,或いは違う形式のデータやりとりが必要となるとする
3. すると､B1→B2アップデート時にはA1も一部の機能の「部分アップデート」が必要となる
4. そこで「A1部分アップデート」が済むまで（A1）'を起動し肩代わりさせる

ただ､仰るように逆に相互依存性が強くなりすぎる等､複雑すぎかも知れませんね(^^;

　　　　　...-ー、,-─　
　　　　 .-=・=-　i､-=・=-　　　
　　　..　　　/ ｰ-' ヽ　　 . . 　
　　　　　　.. -=ﾆ=- 　　　お仕置きしてあげようかね？
　　　　　　　.｀ﾆﾆ´　　

>>99
　ちょいと理解できていないのですが、AとBはどの様な関係にあるのでしょうか？

完成させるまでも相当大変だし、又完成してからもその何十倍何百倍も大変だと思うけど
頑張れ!

>>101

ありゃりゃ､良く見ると>>99は途中でA､Bを(>>71)のものから取り替えてしまって
ロジックが破綻してます｡ そうして見るとロジックでさえ無い orz

一応説明しますと､

・A,Bは同時に動いているマルチカーネルの2つのカーネルの各名称
・1,2の添字はそれぞれのバージョンみたいなもの
・で､この場合の移行は　(B)が(B1)→(B2)、　(A)は(A1)→（A1一部改　= A2）

てな意味でした　(続く）

>>101（続き）

もともと(>>92)
> ・(A1)から(A1)'に移行するときに必要に応じて「移行に適した環境」を整えられる
の「必要性」が「マルチカーネル故に」出てこないか考えた結果でして､

例えば　(A1)が(A2)に替わるときに､もし協調機構が変わったら､(B1)も(B2)替えにゃ
いかんだろなあ、、

と考えただけでして､ロジックになってないし､意味も殆んどないです orz

俺ロジック

・A-よく動く
・B-よく働く
　↓
強調動作でビームとか出る
　↓
明日はホームラン→むしろ野球嫌い→小池栄子はどうでもいい派？
　　　　　　　　　　↓
　　　　　　　エスペラント

>>104
　>>105で思いついたのが協調機構とかは(ある程度)ライブラリ化できないか…ってことなんですがｗ
　あるいは「協調機構」を表す部分だけを自由に書き換えできる機構をつくるとか(^^;
　あとは(A2)や(B2)に、(A1)や(B1)のための「環境を移行するためのルール(関数)」を作成するとか。

　色々話が分からなくなってきてる…orz

で、アーキテクチャは完成してもアーティキチャのままなのかね？
architecture は？

>>1さんへ
マイクロカーネルにする以上、高速性はあきらめるべきだとおもわれ。
そのかわりに、安定化を強化して「高速に思える」ようにするべき。
数値的な効率よりも感覚的な効率の方が(･∀･)ｲｲ!

>>18=>>1 ?

こんなものよりハードウェアが不調でも安定して動くOS作ったほうが有益だと思うがな。

1が何をしたいのかさっぱりわからん。

>>108
えっと>>18さんは､（いまだ釣りの疑いが消えない）>>1氏じゃないですが､
たぶん少し前からここは>>18さんのスレ（になる予定？）です｡

>>106
まあ､ライブラリ化とか書き換え可能とかの私の妄想取り入れると､どんどん複雑に
なるので>>99や >>103-104みたいなのはバッサリ切捨て､ルールはバージョン替わっても
固定､ぐらいに､､､一旦置いときましょうよ｡

と､言いますか､そんな感じでお願いできませんでしょうか？m(_ _)m

A,Bの子プロセス割当の協調方法思いついて書きかけてましたが
また､あわてて書くと「トンでも・メカニズム」になりそうなので､ゆっくり考えてみます

p.s. 2-3日見れなくなりそうです

結局OSを作るんじゃなくて
ライブラリを作ればいいってことか。
そしてそのライブラリを使ってインターフェースを実装した
アプリを作ってやっと対応すると。
うん。結局OS作ればそれだけで完了する問題じゃないんだよな。

報告。
とりあえず、二つのカーネルを起動するブートローダーを
開発しました。
仕組みは簡単。
ブートローダー１を起動
↓
ブートローダー１から
ブートローダー２を起動
↓
ブートローダー２がカーネル１を起動
ブートローダー２を開放
↓
ブートローダー１がカーネル２を起動
ブートローダー１を開放

なお、ブートローダー２はブートローダー１の
リソースを共有するので軽量。

切り替えコマンドでカーネルの切り替えに成功。

ブートローダー１でカーネルを２つ起動してもええんじゃないのか？
Xenと違うのかと思うんだが。

マルチCPU環境で各CPUで別のOSを起動させられるようにするとか、
そういう方面の方が嬉しいな。マルチコアCPUを活用しまくり。

マルチコアつってもHDDやメモリやGPUのリソースは一緒なんだし活用しきるのは難しそうな気も

報告。
このブートローダーからWindowsとLinuxを起動してみたところ
両方のOSがうまく起動しています。
どうやってハードウェアを共有しているのか不明ですが
なんとなく動いているようです。

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

公開お待ちしております。
カーネルなどは無修正でok?

ネタだろネタｗ

どうせブートローダーから動かした
カーネルって自作のカーネルで、
ハードウェアリソースはほぼ利用しない。
ただの小さなプログラム。

っていうのが関の山。

んで、ブートローダーがハードウェアリソースを
共有するためにドライバなどを組み込んで
ブートローダーがOS化するわけだなｗ

>>118
エミュレータでもなければカーネルが無修正で動くわけが無い。

で、こいつはエミュレータ作ろうとしてんの？
だったらまぎらわしい言い方しないで欲しいよね。

colinuxでも

>>1
トリップつけれ(でないと偽者と本物の区別が(ある程度はつくけど)つかない

ネタ(?)の>>117にマジレスすると、両方の(修正なしの)OSは全リソースを使用することを前提にしてるから、
両方が同時に動こうとすると両方(あるいは片方)がコンフリクトで破壊されるのがオチ。
それが無いとすればただのエミュレータな訳だが。

>>124
そんな当たり前の話を偉そうにされても。。。
Xenの開発がんばってください。

ええけつしとるのぉ(*´Д`)ﾊｧﾊｧ
http://219.56.24.98/
http://219.56.24.98/~ss.jpg
http://your-zgxj95zmlh/
http://your-zgxj95zmlh/~ss.jpg

このマルチカーネルOSとやらができても
どうせ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

トリップ付けてみました。これホンモノっす。
アセンブリ言語で簡単にスレッドって
実現できませんかね？

>>129-130

>>130-126-7-129

>>18 >>117は偽者ですので。
マルチカーネルで、
リソース管理とプロセス管理は
カーネル内プロセスで分離しますので、
（つまり、WindowsアプリやLinuxアプリ、専用アプリを
起動管理するカーネル内プロセスは別々で、しかし、
リソース管理は共有とします）
コンフリクトを避けるようにする予定です。

第一行目に誤解を招く表記あり。
改正。
「>>18さん、>>117は偽者ですので。」
すみません。

>>134
だからそれは仮想マシン（エミュレータ）と言うの。
マルチカーネルなんて造語作るな。

プロセスお手玉の強力さが分かってねー子わ居ねがー

プロセスお手玉？ なんだそりゃ。
TCP/IPでも使ってプロセス転送すりゃ住む話だろ。
カーネルレベルでやる話ではない。

マルチカーネルとエミュレーターとの違いを示した、文書をアップしました。
http://jp.msnusers.com/NegishiK/page.msnw
ご意見御願いします。

まだやってたのか・・・。
ネタしつこい。

えっと・・・
説明がemuとvmにしか見えないのはなぜでしょう？

>>138
普及済システム上に大型カーネルとは粋ですね

>>139
せっかくアップしてもらったけどOpenOffice-1.1.4ではレイアウトが崩れて読めません。

カーネル二つって、似たようなことをすでに考えて、
実装した人がいらっしゃるようなんですけど〜

http://osask.jp/os_design.html
>必要ならカーネルが複数同時に動いていても一向にかまいません。

>OSASKでは、OSを終了させることなく、カーネルやデバイスドライバーを入れ替えることができます。これは、２つのカーネルを並行して走らせた状態にした後に、一方を終了することで完了します。

次はOSASKとの違いとメリットを示した、文書をキボンヌ

>>139
見てみましたが､私の能力では何が表現されているのかさっぱりわかりませんでした｡出来れば
ハードウエアリソースを土台にしたよくあるような図で書いて貰えませんか？

しかしその前に､、､そもそも他のOSの互換レイヤとかハードエミュレータとかはカーネルが
それなりの機能をもったしっかりしたものなら原理的には何の上ででも出来るだろうし､実装
方法も色々なバリエーションが可能でしょう｡　どうしてそんなカーネル上のOSサーバや
アプリに近いものの特徴・バリエーションがマルチカーネルの特徴になるんでしょうか？


>>143
そこから引用部をサーチして読むとOSASKでは カーネルとかシェルとかの用語の定義が
一般的なものとは結構違うみたいだし､その比較は妙な混乱を起こす元じゃないですかね？

>>143ご指摘ありがとうございます。
実言うとマルチカーネルはOSASKのアーティキチャーを参考にしています。
（と言っても、既に考えていたときにOSASKを見つけたわけなのですが。）
OSASKでは、Shellをカーネルから独立させます。
しかし、カーネル自身はShellに依存するわけです。
マルチカーネルではそれぞれの依存関係を出来るだけ薄くするのです。
（それぞれのカーネルがそれだけで起動可能なぐらいに。）
ここに大きな違いがあります。

>>144これもまたご指摘ありがとう御座います。
はい、マルチカーネルの"機能"としてアップロードした文章の記載した内容は
マルチカーネルアーティキチャーによる"副産物"と言えるでしょう。
本来は、安定性や利便性、更新の簡易,簡便性、拡張性、移植性かつ"可変性"を向上するのが目的です。
>カーネル上のOSサーバーやアプリ
この言葉、的確にマルチカーネルを表していると思えます。
これからマルチカーネルのことをNetKernelと呼んでみてはどうでしょう？

嗚呼
>144さんの危惧が現実に…

とりあえず、先程初ブートに見事成功しました！(ﾟ∀ﾟ)_!

マルチカー寝るとかネットカー寝るとか
自分用語作ってオナニー支店じゃネーぞ
誰も興味盛ってねーんだから、さげろ。

>>1 スクショぐらい公開しないと

>>147　
トリップまでつけて、「age、アーティキチャー、いきなり動いた」、、、念のいった釣りだな

>>145
OSASKはどうか知らんがカーネルがそれだけで起動できるのは当たり前じゃねぇか

もうちょっとでｵﾅﾆｰOS誕生か。

>>18さん

何かサンプル出来て公開されるとしたら、コピーライト表記とか気をつけて下さいね

どうも>>1氏の発言みてると技術以外にも周りのレスに乗っかって
「それは先に自分が考えてた」とちょくちょく言ってる点が気になる。

まあ先に>>147のコードが出て来て>>1氏の主張する機能が実装されてれば
これは私の下衆の勘ぐりと言う事になりますけどね。

>>1よ、おまへはトリップの使い方を間違っている。

ごめんなさいm(_ _)m
>>152さん、>>153さん
全くその通りです。
自分が少し考え始めていたことを、
周りの人が話し合っていると、
つい「自分が考えていた」と言いたくなりませんか？
・・・いい訳ですね。m(_ _)m
反省します。。。

http://Y043084.ppp.dion.ne.jp/
ｗうはっｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗうぇｗｗｗうはっｗｗｗおｋｗｗｗ
ｗｗｗｗｗｗ

おｋｗｗｗっｗｗｗｗｗｗｗｗｗｗｗｗ

さて、
全く独立したカーネルを沢山走らすのは、
メモリを消費するので、
カーネルをdllの「ようなもの」で構成してはどうでしょうか？
カーネルのプロセスはこの動的ライブラリを参照する機能だけ持っており、
実際の処理はライブラリ内で行われます。
こうすれば、複数のカーネルプロセスがこの動的ライブラリを参照できるはずで、
メモリ消費を抑えられるはずです。

考えた新しい構成
　カーネルA,B,Cを作成する
　通常はAが処理を行う
　BはAが異常事態に陥ってないか常に確認する
　　Aが異常事態に陥っている場合は、BはAの代わりをする
　CはBが処理を行っているか常に確認する
　　Bが処理を行っている場合は、Aを回復させ、Bの処理をAに渡す。

・・・どうでしょう？

ﾏｲｸﾛｶｰﾈﾙに見えてきたなり
Cのﾘｶﾊﾞﾘはどぉするね

CPU毎に１つのカーネルをまかせてグリッドさせるのはどうだね。

>>156
Solaris10のZoneみたいなやつ？

どうでもいいよ。

このスレ終了。

不安定の原因がハードだった場合は意味が無いな。
実際はソフトよりもハード的な原因のほうが多いわけで。
だいたいソフト側が原因で不安定になるカーネルなんてWin9x並みだし使えない。

電源やコンデンサの耐久度ぎりぎりまで追い込んでる安物とかな
安定させたかったら始めからワークステーション名目で売られてるマシン買うし

【マルチカーネルOSを脳内開発中】

【マルチカーネルOSを脳内稼働中】

いまは、二人目

静かになっているね
頑張ってくれ

OSASK とかいうのも開発に長いことかかってるな
ひょっとして本当に >>1 が本気だったとしても、
ﾈﾀかﾏｼﾞか判断に何年も掛かりそうだな。

見てる側としては、カメラで開発している最中の写真とかうｐしてくれた方が、
より真実味を帯びてくると思うんだが

開発風景
ttp://www.amazingty.com/images/dnotytt0034.jpg
ttp://www.dennio.com/tgp/phole2/amtpeehole0003.JPG

>>167
タイ━━━━||Φ|(|´|Д|`|)|Φ||━━━━ホ

>>1
まずは理想を全て捨て、只普通のOSを作ってみるべきでしょう。
それからマルチカーネルだろうが、好きにしましょう。
ってか普通のOSを作れない人が、マルチカーネルなOSを作れません。

普通のOSを製作しているMonaプロジェクトがどれだけ時間が掛かっているかを
考えましょうね。

考えることはサルでも出来る。その程度の思想は考えつくされてきているはずである。
なのに現実に全く出て来ていないのは、みんなの技量の問題ではなく、
成果が出ないことの表れである。

まぁ考えること、ガムシャラに頑張ることは悪いことではない。
それをのちのちに有益な財産としてくれれば。

なんだかさ、Intel な MacOS X で Darwine 完成する方が楽そうに見えるのは、私だけでしょうか？
Linux API もついてるし....

>>167
ｲﾀｿｰ

尿道拡張はイカれ杉

>>1はそんな簡単なこともできないのか?
2個のタスクをリアルに同時実行させるなら、2個のPCを合体させてやりゃいい。

ｸﾏ

PC/ATでタスクスイッチってタイマー割り込みなんだよね。
割り込みとかはOSの専権事項であるわけで、Winとかも自分勝手に使えると思ってる。

マルチにOSを走らせた場合は、タイマー割り込みとかはどう調停されるんだろう。
片方のOSが無効化しているときはもう片方のOSに割り込みが届かなくなってしまう？

結局>>1はタスクスイッチが"できる"ものと考えてOSを作っているが、タスクスイッチはOSが"する"もの。
アイディアのスタートする立ち位置がすでにOSではなくアプリケーションなのが最大の間違いだな。

ｸﾏ

>>167 >>168 >>171
怖くて見れねーよ。一体何の画像なんだ？

>>167
こんなにしたら、どっち使ってるか分かんなくなっちゃうじゃないか！
ってか、これじゃぁ、リークしまくりにならんのか？

s

完成まだー

はにゃ？

　　　　[ ﾟдﾟ]y-~~~　ﾃﾞﾌﾗｸﾞｶﾞｶﾝﾘｮｳｼﾏｼﾀ
　　　　/[へへ
、、。。。いいうええごさししすすせせそたつつつつてててでにににののははままもよらりるるれ
ををををををアィイオカカカキクチッテドネネネバヘマメモャリルルルローーーーーーー一二低
共同実展意抑持時有発考行見速

>>179
>>70

このアイデアってVMwareだよね？

今ある代表的なカーネルって

・モノシリックカーネル（Unix、Linux系）
・マイクロカーネル（Minix,Mona）
・ハイブリッドカーネル（Mac OSX）

こんなもんか？Windowsはどうなってんだろ？

>>1のマルチカーネル云々はどうでもいいんだが
次世代カーネルみたいな研究ってされているのかな？

とりあえず、あげとく

Mac OS をハイブリッドというなら WinNT もハイブリッドだろうなぁ

つ ttp://wiki.osdev.info/?JP-OS

>>1
VMMってしらねーの？

ご参考までに

すれ違いかもしれないですが。
今後メインのカーネルをハードウェアないし、マイクロコード等で実装するような動向はないのですか？？

それこそ脱x86みたいな

マイクロコードで実装、というのは基本的に廃れた技術。
なぜかというと低水準な機能をハードウェアで剥き出しで実装して、あとはコンパイラに
任せる、というRISC流の方法であれば、ソフトウェアの柔軟性のご利益があるわけだが、
そこをマイクロコードでハードウェア化しちゃうと、ちょっとした性能向上とひきかえに、
柔軟性がなくなってしまう。「柔らかいハードウェア」も研究されたことはあるが望み薄
（と俺は見ている）。

そういう高水準の機能をワイヤードロジックで実装しようってのは正気じゃないでしょう。
複雑過ぎる。

RISCがベストならx86はどうなんだという話になるけど、x86は結局、過去の遺産の継承の
ベネフィットと利益率が高くかつ大量生産（数だけで言えば組込みRISCも結構行くが）
という規模の利益が、技術的な議論を凌駕しちゃってる。

今後ハードウェア化する意味のあるのは、特に並列化がらみでソフトウェアでの実装が
面倒な並行・並列処理のプリミティブとかぐらいじゃないかな、と（GPUとかを別にすると）。

あとはIBMのAS/400みたいな方向性だろうけど、あのレベルの仮想化はハードウェアで
実装するより、JavaVMとか.NETのCILとかLLVMのようなソフトウェアのレイヤで実現する
ほうが現実的だと思うね。

>>1の考えてるような、複数のカーネルを走らせて相互監視させてひとつでも死んだら他のカーネルが叩き起こすみたいなことって本当にできるのか？

メインフレームとか電話交換機みたいな機械とかで

>>191
sun1 だったかsun2 だったか、68000 の片割れがこけると、もう一方が叩き起こしていた、らしい。

>>193
ありがとうございます

>>193
あーその伝説は微妙にウソ。
ttp://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html
ここに詳しく書いてあるが、初代68000はページフォールトを起こした時に、
コンテキストを保存してページを入れ替えて再開、ということができなかったので、
フォールトを起こしたらプロセッサを止めて、別のプロセッサがページを入れ替え、
入れ替えが済んだら元のプロセッサの実行を再開、ということをやったマシンが
あった、という話。

>>195
伝説でしたか。
でもこのトリックは、ページング関連ではなくてスーパーバイザ命令の割り込み関連の問題の回避のため、ときいているのですが。

Barrelfishのスレと聞いて

最近の仮想化対応のハードならなんでもありなんだろうけど、
そうでなければデバイスドライバに偽装するのが現実的？

例えば新しいデバイスに対応したOSaと古いデバイスに対応したOSbがあって、
両方サポートしたOSがない場合、ダミードライバが呼ばれた時に相手のOSにスイッチして、
その本物のドライバに仕事させて、それをダミードライバにトンネリングする。

つまり、適当なタイミングないしサポート外のデバイス（ダミードライバ）が呼ばれたら
相手のOSにスイッチするようにすることで、
個々のデバイスの詳細を知らなくてもそれぞれのOSドライバの作り方さえ知っていれば、
事実上デバイスフルサポートのOSが手に入ることになって、
これって考えてみるとおいしい話じゃないだろうか？なんか落とし穴あるかな？

結局これって分類的にはハイブリッドカーネルなんだろうか？

＠

マルチカーネルにしたらマルチタスクの実装がややこしくならない？

posix系とかのヘビーなOSに軽量のリアルタイムOSを同居させて、
リアルタイムカーネル化とか言ってた奴の場合はどうなの？

共有メモリにするんだから、必然的にメモリ管理も共有することになる
なので「親カーネル」は必要ないな

奴隷にいかに仕事をさせるかというテーマかのう？

カーネルも階級制度が必要な時代になったのか？ｗｗ

カーネル・サンダースX2

９８０円セット２個でお大尽なOSｗ

DOSSHELL

マスタ・カーネル
スレーブ・カーネル

ああ、2005年のスレか・・・
今こんな事言ってたら、相当のバカだったね

マルチいいね