walden@zippy.eecs.umich.edu (Eugene Marvin Walden ) (11/28/89)
I am wondering if MACH is a good option to run with for a system that
currently has a large base of software already written, say for example,
a MAC II or a SUN 3. If you install MACH on a Sun 3, do you lose all of
the software that requires SUNOS, or can you somehow layer SUNOS on top
of MACH? If you do lose all of the software, could someone who has switched
to using MACH explain their motivation to me? Why was it a good choice for
you?
- Eugene Waldenmt@cleo.cs.wisc.edu (Manolis Tsangaris) (12/08/89)
In article <942@zip.eecs.umich.edu> walden@zippy.eecs.umich.edu (Eugene Marvin Walden ) writes: > > I am wondering if MACH is a good option to run with for a system that >currently has a large base of software already written, say for example, >a MAC II or a SUN 3. If you install MACH on a Sun 3, do you lose all of >... It seems to me that the way MACH is structured, makes it easy to have guest operating systems, i.e. emulate some popular operating systems: 1. Theoritically you could redirect all systems calls to a user level server that implements the guest OS semantics. This assumes that all traps are converted to messages, and sent to the kernel port(s). 2. Playing with the memory maps you could give programs their familiar ``global variable'' environments. Or fool them to believe they read/write the screen memory. 3. Handling exceptions, you could allow accesses to nonexistent I/O devices. [Only for the case of non memory mapped I/O]. Under Mach most instruction exceptions are turned into messages that go to the exception port. 4. The binary format of MACH (MACH-O) can be used to give special instructions for running a foreign OS program. For example make sure to have the ports set up right or map in the proper memory segments. I guess that similar things could be achieved using inheritence. Since source code is not available in most commercial programs, binary compatibility is necessary. So the question is how much of the above is possible with no compilation of programs. Another concern is the performance penalty when using all those redirections. A simple Macintosh ``system call'' is a trap. In case of a guest Macintosh OS, we have a trap followed by a context switch to the Mach kernel (remember all Macintosh programs run in the privileged mode, so there is no context switch there !), a message generated to the kernel port, another context switch to the server to receive the message, e.t.c. Many 386-based operating systems (like SUN-OS4.0 for SUN386) successfully and efficiently emulate the ``dumb'' MSDOS environment, even accesses to raw PC (I/O devices and others). However that required enough support from the kernel and of course from the 386 itself. Remember that 386 has been built with 8086 compatibility in mind. A MACH environment on a 68000 could possibly emulate a Macintosh environment. But unless the whole COPYRIGHTED ROM code is transferred to Mach and runs, the task of providing the same services will be a very complex one. For example many of the ROM services are buggy or obsolete, so they have been patched by APPLE or by user programs. Things seem much easier with UNIX-like environments (e.g. System V). Their similarity with BSD 4.3 which is already supported on MACH, could be exploited. Semantics different than BSD can be provided by some user/level servers or libraries. But the key point will be the performance. Mach people chose to implement 4.3 compatibility inside the MACH kernel. Perhaps performance of a user level 4.3 kernel was unacceptable. Even if this is the case, great CS/OS projects could be given to write small guest OS's on Mach (:-). --mt(Manolis Tsangaris) ----------------------------------------------------------------------------- P.S. Any ideas how the name MACH was chosen ? Any speed considerations ? (mach = speed of sound waves, I thing).