Rogelio Serrano wrote:
On 5/6/07, W B Hacker <[EMAIL PROTECTED]> wrote:
*snip*
>
... OR machine-coding the 'primitives' for your own virtual-machine
to obviate
the need for having to worry about it at all.
i see. theres a good idea there somewhere. some sort of vm... highly
optimised.
well it can be done. but to abstract all hardware, not possible. it
will be very complicated and dog slow.
Seems otherwise. See Xen, Qemu, VMware, L4 & descendents, Inferno - not to
mention the long-running won't die revenue king of them all IBM's MV/VM.
And 'abstract all' needs a virtual dual-ported area of RAM set aside and mapped
where it has to be, interrupt handlign to go - not too much else.
Dangerous in the 'wrong hands' but simple enough. or see what DragonFly is doing
w/r hand offs for so-far-native-DFLY-only virtual kernels. There may be soem
meat on that bone.
Only a few of these get at all close to the hardware, yet the speed for the best
of them (seldom the same answer in every environment) is more than 'good
enough' to do a great deal of useful thigs - devel at the head of the list.
I daresay there are few folks here who have not used them or come to appreciate
them as time-savers vs rebooting 'hardware' native installs.
Even so - hardware doesn't *necesarily* have to change - multicore and privilege
separation are fairly recent additions to commodity (x86/AMD) silicon and by no
means fully utilized by all comers.
So there *could* be more of these written to run as direct 'native' hosts, and
probably will be...
But that doesn't really change the asm / C / whatever 'need set'.
Just lets it be buried a little deeper under the covers.
Still no one-size fits all, though.
Bill
