karl@sugar.uu.net (Karl Lehenbauer) (02/20/89)
In article <7541@venera.isi.edu> raveling@isi.edu (Paul Raveling) writes: > MACH is probably the best bet at present, thanks to a > layer to allow BSD compatibility. ... This is afforded by the presence of BSD in Mach -- it's not just BSD compatible, BSD is in there. The Mach people at CMU are in the process of moving the BSD stuff out of the kernel. When they are done, Mach will be sort of a virtual operating system; that is, it will be a platform for the creation of processes and threads within processes, provide memory management, have support for program-specified VM pagers, and provide calls for communicating to other tasks via message ports where the mechanism of the intertask communication, whether uniprocessor, multiprocessor with some shared memory, multiprocessor with entirely shared memory or loosely or tightly coupled communicating multiprocessors. As such, even VMS could be made to run under Mach. Part of the great appeal of Mach is that, on a local area network of Mach- based workstations, your Mach machine will go out and run some of your processes on other idle Mach machines behind your back. Further, Mach holds the promise of supporting multiprocessing inside your workstation for all the major modern buses, Futurebus, VME, Multibus II, even MCA and EISA. The prospect of shoving extra processor cards into a box and getting higher performance without changing any code is at hand. The Next machine may be an early leader in providing this capability, as it is already Mach-based and it's a board in a VME backplane rather than a motherboard, so they're set. Eugene Miya (or is it 'eugene miya?') laments that Mach is tied to 32-bit architectures. I presume he would like it to run on smaller machines, because it should work OK on bigger ones. He's right though, in the sense that Mach does absolutely require a machine supporting virtual memory to run. However, this includes every 386, which means over a million Mach- capable machines are being built per year, plus of course every Vax, 68020 with MMU, 68030, etc. Mach purports to bring unity, clarity, and new utility to a VM model, along with architecture independence. (I say 'purports' because I've only read about it.) For example, Mach supports the highly disparate virtual memory mechanisms of the IBM PC/RT and the Vax. A benefit of the Mach VM model: passing big messages to other tasks is accomplished by memory mapping rather than copying when possible. Mach makes heavy use of copy-on-write to avoid unnecessary copying, a la BSD's vfork and System V fork (System V is superior to BSD is this respect, gasp). -- -- uunet!sugar!karl | "Everyone has a purpose in life. Perhaps yours is -- karl@sugar.uu.net | watching television." -- David Letterman -- Usenet BBS (713) 438-5018
anand@amax.npac.syr.edu (Anand Rangachari) (03/02/89)
In article <3471@sugar.uu.net> karl@sugar.uu.net (Karl Lehenbauer) writes: >because I've only read about it.) For example, Mach supports the highly >disparate virtual memory mechanisms of the IBM PC/RT and the Vax. >A benefit of the Mach VM model: passing big messages to other tasks is >accomplished by memory mapping rather than copying when possible. Mach makes >heavy use of copy-on-write to avoid unnecessary copying, a la BSD's vfork and >System V fork (System V is superior to BSD is this respect, gasp). It is interesting that you bring this up. I attended a talk by Richard Rashid (designer of Mach) a few days ago when he discussed this point. His team has been so successfull in getting Mach to run on a number of machines by essentially not using most of the memory management facilities. In fact, it seems that programs run faster under Mach than SunOS on the Sun 3 even though Mach does not make full use of the facilities provided by the Sun MMU. R. Anand Internet: anand@amax.npac.syr.edu Bitnet: ranand@sunrise #! rnews