アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
何を動かすの? (スコア:2, 参考になる)
Mac OS X用のソフトにしても、iTunesみたいなのがサクッと動いちゃうならかなりびっくりするし、有益かもしれませんが、、、
Re:何を動かすの? (スコア:0)
いや、実利よりは技術的興味でやっているというのは分かっていますが、
NetBSD 側から見た問いかけが出たので、 Mac OS X 側から見るとどうかなと。
Re:何を動かすの? (スコア:0)
Re:何を動かすの? (スコア:0)
NetBSDってとりあえず他のOSのバイナリ代わりとなんでもかんでも動いてしまったりするのですが、そのおかげかどうかNetB
Re:何を動かすの? (スコア:1)
>「各種Unix系OSでの互換性が高くなっている」というのとは
>全然違う。
NetBSD/i386でLinuxエミュレーションといわれているものは、
切り口だけすり合わせたもので、本質的にエミュレーションでは
ないんですけどね。
#system callの入り口がlinuxの流儀にあわせてあるだけで
#実行自体はエミュレーションでもなんでもない。
#CPUアーキテクチャが異なる場合にバイナリを動かせないのはそのため。
Unix系の互換性が云々、ってのは完全に同意です。
#つーか、CPUアーキテクチャが全く違うものに関し
---- redbrick
Re:何を動かすの? (スコア:0)
だからその「切り口を合わせる」ことをエミュレーションと呼んでるんだわさ。
そもそも「本質的にエミュレーションではない」ってなに?
CPUアーキテクチャが異なると動かないのはlinuxPPC/linux(i386)の場合でも同じだよね
Re:何を動かすの? (スコア:1)
#ダメだったかな・・・?
>だからその「切り口を合わせる」ことをエミュレーションと
>呼んでるんだわさ。
それだと呼び方が大雑把で混乱するので、もっと詳しい定義付けを
しませんか?
PPCでのm68kエミュレーションやi386エミュレーション(Virtual PC)の、
CPUエミュレータ(バイナリ変換あり)なんかとは本質的に違うものだし、
Real PCなんかのハードウェアのエミュレータ(こっちはマシンの仮想化?)
とも違うわけだから。
#NetBSDのlinuxエミュレータと呼ばれているものは、system callの
#すり合わ
---- redbrick
Re:何を動かすの? (スコア:0)
どーーーーしても、宗教上の理由かなんかでアレをエミュレーションと呼ぶことができないなら毎回「NetBSDがいうところのバイナリエミュレーション」と書きゃいいのだよ。ひょっとすると相手も付き合ってくれるかもしれない。省略して「バイナリエミュレーション」と呼ぶかもしれないけど、それこそ「文脈で解釈してくれ」。
それができないってことは自然言語が解釈できないってことだ。
で。ここからが本題。
redbrickさんの「エミュレータ」の定義には「実行時にオーバーヘッド」があるものなわけね。
NetBSDのバイナリエミュレーションに実行時オーバーヘッドがないとでも?
パスの仮想化と呼べない事もない /emul/linux/ 以下へのファイルアクセスのすげ替えとかやってるんだが。
#まぁ「マシンの仮想化」といえないこともないな。
これからは「redbrick的」にも「エミュレーション」と呼んでもらえるでしょうか?
Re:何を動かすの? (スコア:0)
あなたのいうところの「エミュレーション」とは「オーバーヘッドのある処理」と等価なんですか。
で、これは何と呼べばいいんでしょうね?「#245090がいうところのエミュレーション」ですか?
Re:何を動かすの? (スコア:0)
s/#245090/redbrick/g
質問する相手が間違ってる。
Re:何を動かすの? (スコア:0)
>redbrickさんの「エミュレータ」の定義には「実行時にオーバーヘッド」があるものなわけね。
これは「redbrickが言うところのエミュレータ」の定義の確認。わたしがそう思ってるわけではない。
#244737 [srad.jp]で
>#NetBSDのlinuxエミュレータと呼ばれているものは、system callの
>#すり合わせをやってるけど、binary変換はないから、実行時に
>#オーバーヘッドはないので、ある意味エミュレータとは
>#言えないでしょ?
#強調はわたし
と主張しているのでNe
Re:何を動かすの? (スコア:1)
わたしより詳しい人がもう書いてるので、とりあえずわたしの中での
定義の明確化だけ、書きます。
#自分の中の勝手な定義なので、全ての呼称がこうでなきゃ、とかは
#全く思ってません。
#定義の明確化、とかいいつつ自分で書いてないせいで要らぬ混乱を
#招いてしまった事に対する謝罪のつもりです。
#すみませんでした>all
実行形式の違う、CPUアーキテクチャから違う場合にCPUエミュレータと呼びたい。
理由:他アーキテクチャのCPUの動作を真似るか、バイナリ変換処理をかけるので。
ハードウェア全体を仮想化する場合はハードウェアエミュレータと 呼びたい。
理由:物理的には存在しないハードウェア動作を真似るため。
どちらも、物理的に存在しないものの動作を真似ることが中心にある、と
認識してます。
で、NetBSDが言うところのバイナリエミュレータでは、CPUの中で
実行される命令はnativeなので、物理的にはCPUで普通に命令を
実行しているに過ぎない。
真似ているのは入出力のインターフェースの切り口の形状、と
言ったらいいのかな?
#もちろん、pathの切り替え、必要なsystem callの切り口の準備、
#という仮想的な環境の下準備と実行時の切り口の変換操作は
#あるわけだけど。
#ソフトウェア側でLinux環境が物理的に存在しない??
#いや、でもLinux emulator使うときにはlibraryとかも準備するはずだし・・・。
オーバーヘッドというよりは、CPUがnative命令を受け取るかどうか、
その前に変換操作でバイナリ実行形式自体をいじらなければならなかったり、
仮想化したCPUを動かす必要があるかどうか、ってのが気になります。
#オーバーヘッドがない、というのはNetBSDの言うバイナリエミュレータの
#宣伝文句から引っ張ってきたんだけど、それが頭に強く残っていた
#ので使いました。
#実行形式の違いを先に言っておけばよかったかな?
#結局、CPUアーキテクチャの制限から抜け出せないものを
#バイナリエミュレータとは呼びたくないって思いもあるのだけど、
#それはわたしの思い込みだけだし・・・。
それで、NetBSDが言うところのバイナリエミュレータ(長い・・)は、
他のCPUのバイナリが実行できるエミュレータと混同しないためには
別の呼称、もしくはもっと実際に即した、「Linux環境エミュレータ」とか
「Linux system callエミュレータ」というようにした方がいいと
思ってるんですよ。
#実はm68k使ってて、
#「Linuxのバイナリエミュレータ? うそぉ、Linux(当然i386)の
#バイナリがこれでも動くんか?」
#って、ぬか喜びしたクチなので(苦笑)。
#その時にはm68kってLinuxは全然開発進んでなくってね・・。
#わたしももっと無知で、Linuxってーとi386しか思いつかなんだ。
---- redbrick