Editing Mach (kernel) (section)

===Mach===
The major change between these experimental kernels and Mach was the decision to make a version of the existing [[Berkeley Software Distribution|4.2BSD]] kernel re-implemented on the Accent message-passing concepts. Such a kernel would be binary compatible with existing [[Berkeley Software Distribution|BSD]] software, making the system immediately available for everyday use while still being a useful experimental platform. Additionally, the new kernel would be designed from the start to support multiple processor architectures, even allowing heterogeneous clusters to be constructed. In order to bring the system up as quickly as possible, the system would be implemented by starting with the existing BSD code, and gradually re-implementing it as [[inter-process communication]]-based (IPC-based) programs. Thus Mach would begin as a monolithic system similar to existing UNIX systems, and progress toward the microkernel concept over time.<ref name="IghTyn" />

Mach started largely being an effort to produce a clearly defined, UNIX-based, highly portable Accent. The result was a short list of generic concepts:<ref name="Tev97">{{cite conference|title=Mach Threads and the Unix Kernel: The Battle for Control|conference=USENIX Summer Conference|publisher=[[USENIX]]|year=1987| url=http://repository.cmu.edu/cgi/viewcontent.cgi?article=2728&context=compsci| last1=Tevanian|first1=Avadis|author-link=Avadis Tevanian| last2=Rashid|first2=Richard F.|author2-link=Richard Rashid| first3=David B.|last3=Golub| first4=David L.|last4=Black| first5=Eric|last5=Cooper| first6=Michael W.|last6=Young| pages=185–197| citeseerx= 10.1.1.41.3458}}</ref><ref name="xGxrt">{{cite conference| title=Mach: A New Kernel Foundation for UNIX Development| year=1986| conference=USENIX Summer Conference| publisher=USENIX| first1=Mike| last1=Accetta| first2=Robert| last2=Baron| first3=William| last3=Bolosky| first4=David| last4=Golub| first5=Richard| last5=Rashid| author5-link=Richard Rashid| first6=Avadis| last6=Tevanian| author6-link=Avadis Tevanian| first7=Michael| last7=Young| url=http://www.cs.ubc.ca/~norm/508/2009W1/mach_usenix86.pdf| access-date=April 4, 2015| archive-date=July 6, 2017| archive-url=https://web.archive.org/web/20170706060151/http://www.cs.ubc.ca/%7Enorm/508/2009W1/mach_usenix86.pdf| url-status=dead}}</ref>
* a "[[task (computing)|task]]" is a set of system resources that produce "threads" to run
* a "[[thread (computing)|thread]]" is a single unit of execution, existing within the context of a task and shares the task's resources
* a "[[port (computer networking)|port]]" is a protected [[message queue]] for communication between tasks; tasks own send and receive rights (permissions) to each port.
* "[[message (computer science)|messages]]" are collections of typed data, they can only be sent to ports—not specifically tasks or threads

Mach developed on Accent's IPC concepts, but made the system much more UNIX-like in nature, making it possible to run UNIX programs with little or no modification. To do this, Mach introduced the port, representing each endpoint of a two-way IPC. Ports had a concept of permissions like files under UNIX, permitting a very UNIX-like model of protection to be applied to them. Additionally, Mach allowed any program to handle privileges that would normally be given to the operating system only, in order to permit [[user space and kernel space|user space]] programs to handle things such as controlling hardware.

Under Mach, and like UNIX, the operating system again becomes primarily a collection of utilities. As with UNIX, Mach keeps the concept of a driver for handling the hardware. Therefore, all the drivers for the present hardware have to be included in the microkernel. Other architectures based on [[Hardware Abstraction Layer|hardware abstraction layer]] or [[exokernel]]s could move the drivers out of the microkernel.

The main difference with UNIX is that instead of utilities handling files, they can handle any "task". More operating system code was moved out of the kernel and into user space, resulting in a much smaller kernel and the rise of the term [[microkernel]]. Unlike traditional systems, under Mach a process, or "task", can consist of a number of threads. While this is common in modern systems, Mach was the first system to define tasks and threads in this way. The kernel's job was reduced from essentially being the operating system to running the "utilities" and providing them access to the hardware.

The existence of ports and the use of IPC is perhaps the most fundamental difference between Mach and traditional kernels. Under UNIX, calling the kernel consists of an operation named a ''[[system call]]'' or ''[[signal (IPC)|trap]]''. The program uses a [[library (computing)|library]] to place data in a well known location in memory and then causes a ''[[fault (computing)|fault]]'', a type of error. When a system is first started, its kernel is set up to be the "handler" of all faults; thus, when a program causes a fault, the kernel takes over, examines the information passed to it, then carries out the instructions.

Under Mach, the IPC system was used for this role instead. To call system functionality, a program would ask the kernel for access to a port, then use the IPC system to send messages to that port. Although sending a message requires a system call, just as a request for system functionality on other systems requires a system call, under Mach sending the message is pretty much all the kernel does; handling the actual request would be up to some other program.

Thread and concurrency support benefited by message passing with IPC mechanisms since tasks now consist of multiple code threads which Mach could freeze and unfreeze during message handling. This permits the system to be distributed over multiple processors, either by using shared memory directly as in most Mach messages, or by adding code to copy the message to another processor if needed. In a traditional kernel this is difficult to implement; the system has to be sure that different programs do not try to write to the same region of memory from different processors. However, using Mach ports makes this well defined and easy to implement, so Mach ports were made [[first-class citizen]]s in that system.

The IPC system initially had performance problems, so a few strategies were developed to improve performance. Like its predecessor, Accent, Mach used a single shared-memory mechanism for physically passing the message from one program to another. Physically copying the message would be too slow, so Mach relies on the machine's [[memory management unit]] (MMU) to quickly map the data from one program to another. Only if the data is written to would it have to be physically copied, a process called "[[copy-on-write]]".

Messages were also checked for validity by the kernel, to avoid bad data crashing one of the many programs making up the system. Ports were deliberately modeled on the UNIX file system concepts. This permits the user to find ports using existing file system navigation concepts, as well as assigning rights and permissions as they would on the file system.

Development under such a system would be easier. Not only would the code being worked on exist in a traditional program that could be built using existing tools, it could also be started, debugged and killed off using the same tools. With a [[monolithic kernel|monokernel]] a bug in new code would take down the entire machine and require a reboot, whereas under Mach this would require only that the program be restarted. Additionally the user could tailor the system to include, or exclude, whatever features they required. Since the operating system was simply a collection of programs, they could add or remove parts by simply running or killing them as they would any other program.

Finally, under Mach, all of these features were deliberately designed to be extremely platform neutral. To quote one text on Mach:
:Unlike UNIX, which was developed without regard for multiprocessing, Mach incorporates multiprocessing support throughout. Its multiprocessing support is also exceedingly flexible, ranging from shared memory systems to systems with no memory shared between processors. Mach is designed to run on computer systems ranging from one to thousands of processors. In addition, Mach is easily ported to many varied computer architectures. A key goal of Mach is to be a distributed system capable of functioning on heterogeneous hardware.<ref>([https://www.os-book.com/OS9/appendices-dir/b.pdf Appendix B], [https://www.os-book.com/OS9/index.html Operating System Concepts])</ref>

There are a number of disadvantages, however. A relatively mundane one is that it is not clear how to find ports. Under UNIX this problem was solved over time as programmers agreed on a number of "well known" locations in the file system to serve various duties. While this same approach worked for Mach's ports as well, under Mach the operating system was assumed to be much more fluid, with ports appearing and disappearing all the time. Without some mechanism to find ports and the services they represented, much of this flexibility would be lost.