Re: [9fans] speaking of kenc

[W B Hacker <wbh@conducive.org>]

Rogelio Serrano wrote:
> On 5/6/07, W B Hacker <wbh@conducive.org> 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