[HECnet] Trying to build SIMH from git (on OpenIndiana)

below On Thu, Mar 21, 2013 at 9:20 AM, Johnny Billquist <bqt at softjar.se> wrote: They call it a "hybrid", whatever that might mean A performance hack is what it means. Ok, I was a tad sloppy and skipped some steps for brevity - my apologies. CMU created Mach by starting with the Pascal based ukernel Accent from the CMU SPICE project and marrying it with BSD UNIX to bring the user space along. Accent is a true uKernel written for the "Pascalto" (aka the Triple Drip Perq) and CMU rewrote the porting they anted into C and hacked originally BSD 4.1 - ripping out the primariarly the memory and tasking system and widely released became Mach 2.5 after the BSD 4.2 upgrade. So yes, the API is BSD 4.2, plus the Mach calls. The Messaging, Tasking and Memory support is all CMU (modeled/based on Accent) and support the communications concept of a "port" - which is a distributed message capability. The drivers for were BSD and it originally ran on the VAX. The BSD 4.2 command system was also basis for the distribution. I do not remember when the "BSD NET2" code replaced the BSD 4.2 code - but for the purposed of this discussion I will call them the same [grab me off line if you really what to know the differences]. The key is that CMU envisioned Accent and Mach (and for that matter Accent's for runner - RIG) as distributed OS's which is why the ukernel ideas important. ukernels are message based and message based systems are >>much<< more natural for NORMA (no remote memory access) "multicomputers." But many people (like me) felt that ukernels were just a better way from a software engineering standpoint to build a kernel, since the way the system structured. But ... Mach 2.5 was a monolithic kernel and because of the BSD basis had support for many different architecture families, from Vax to 68K, NS32000, iPX386 etc and thus would be able to migrate from CMU to places like NeXT, OSF et al. At the time of the Mach 25 release, CMU had started to work on a pure ukernel called Mach 3.0 which was not completed at CMU, but rather at the OSF/RI and a number of partners. Including my then employer - Locus Computing Corp - who was working as kernel hackers for for hire for most of the major players [DEC, Sun, HP, IBM, or in the case of OSF/1 - Intel]. At OSF and friends a lot of time and study was done considering the performance issues of a pure kernel vs. the monolithic (using the 2.5 and 3.0 based kernels on a 386). The hybrid approach is a hack to allow, some of the system "servers" to continue to be bound into the address space of the kernel so, that two messages are not needed for those system calls. The "hybrid" idea came from the fact that for 3.0 ukernel, the memory support still is part of the kernel itself (in many ukernels like the grand daddy of them all - Dykstra's THE - the memory support is also a "server layer" in "user" space). In fact, the Mach 3.0 "micro kernel" was about 1-1.5 megabytes on a 386 which is hardly "micro" (at the time people were proposing a "nano-kernel" to solve that]. So the hybrid kernel allows the kernel behave like a pure ukernel when desired, but still allows the performance benefits of a monolithic kernel. Of course because its not a pure ukernel, it suffers all of the security issues and more difficulties of distribution for the kernel across multiprocessors that monolithic kernels have. Clem