From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sun, 6 May 2007 16:12:42 +0800 From: "Rogelio Serrano" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] speaking of kenc In-Reply-To: <463D8BA4.40804@conducive.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <54fc0f1102d30ae5933e78e2e391032f@proxima.alt.za> <463D648C.4040703@conducive.org> <463D8BA4.40804@conducive.org> Topicbox-Message-UUID: 5c9c4ece-ead2-11e9-9d60-3106f5b1d025 On 5/6/07, W B Hacker wrote: > Rogelio Serrano wrote: > > On 5/6/07, W B Hacker 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. > i see. it does not need to be as big as that actually. just enough to avoid writing x86 assembler. and that "blob" can be written using a c programmer and then generate object code that can be "linked" to the kernel. well what im writing is more of an "event core". there is no kernel actually. but the event core without assembly, generated from machine definitions is a good idea actually.