Mach ядролық жүйесі және оның даму тарихы

Operating system microkernel

Mach (/m//ɑː//k/) is a kernel developed at Carnegie Mellon University by Richard Rashid and Avie Tevanian to support operating system research, primarily distributed and parallel computing. Mach is often considered one of the earliest examples of a microkernel. However, not all versions of Mach are microkernels. Mach's derivatives are the basis of the operating system kernel in GNU Hurd and of Apple's XNU kernel used in macOS, iOS, iPadOS, tvOS, and watchOS. The project at Carnegie Mellon ran from 1985 to 1994, ending with Mach 3.0, which is a true microkernel. Mach was developed as a replacement for the kernel in the BSD version of Unix, so no new operating system would have to be designed around it. Mach and its derivatives exist within a number of commercial operating systems. These include all using the XNU operating system kernel which incorporates an earlier non microkernel Mach as a major component. The Mach virtual memory management system was also adopted in 4.4BSD by the BSD developers at CSRG, and appears in modern BSD derived Unix systems such as FreeBSD. Mach is the logical successor to Carnegie Mellon's Accent kernel. The lead developer on the Mach project, Richard Rashid, has been working at Microsoft since 1991; he founded the Microsoft Research division. Another of the original Mach developers, Avie Tevanian, was formerly head of software at NeXT, then Chief Software Technology Officer at Apple Inc. until March 2006. later asked project leader Rick Rashid about the project's current title and received "MUCK" as the answer, though not spelled out but just pronounced: which he, according to the Italian alphabet, wrote like Mach. Rashid liked Giuse's spelling "Mach" so much that it prevailed.

A key concept in the original Unix operating system was the idea of a pipe. A pipe was an abstraction that allowed data to be moved as an unstructured stream of bytes from program to program. Using pipes, users (or programmers) could link together multiple programs to complete tasks, feeding data through several small programs in turn. This contrasted with typical operating systems of the era, which required a single large program that could handle the entire task, or alternately, used files to pass data, which was resource expensive and time consuming. Pipes were built on the underlying input/output system. This system was, in turn, based on a model where drivers were expected to periodically "block" while they waited for tasks to complete. For instance, a printer driver might send a line of text to a line printer and then have nothing to do until the printer completed printing that line. In this case, the driver would indicate that it was blocked, and the operating system would allow some other program to run until the printer indicated it was ready for more data. In the pipes system the limited resource was memory, and when one program filled the memory assigned to the pipe, it would naturally block. Normally this would cause the consuming program to run, emptying the pipe again. In contrast to a file, where the entire file has to be read or written before the next program can use it, pipes made the movement of data across multiple programs occur in a piecemeal fashion without any programmer intervention. However, implementing pipes in memory buffers forced data to be copied from program to program, a time consuming and resource intensive operation. This made the pipe concept unsuitable for tasks where quick turnaround or low latency was needed, such as in most device drivers. The operating system's kernel and most core functionality was instead written in a single large program. When new functionality, such as computer networking, was added to the operating system, the size and complexity of the kernel grew, too.

Unix pipes offered a conceptual system that could be used to build arbitrarily complex solutions out of small interacting programs. These smaller programs were easier to develop and maintain, and had well defined interfaces that simplified programming and debugging. These qualities are even more valuable for device drivers, where small size and bug free performance are extremely important. There was a strong desire to model the kernel itself on the same basis of small interacting programs. One of the first systems to use a pipe like system underpinning the operating system was the Aleph kernel developed at the University of Rochester. This introduced the concept of ports, which were essentially a shared memory implementation. In Aleph, the kernel itself was reduced to providing access to the hardware, including memory and the ports, while conventional programs using the ports system implemented all behavior, from device drivers to user programs. This concept greatly reduced the size of the kernel, and allowed users to experiment with different drivers simply by loading them and connecting them together at runtime. This greatly eased the problems when developing new operating system code, which otherwise generally required the machine to be restarted. The general concept of a small kernel and external drivers became known as a microkernel. Aleph was implemented on Data General Eclipse minicomputers and was tightly bound to them. This machine was far from ideal, since it required memory to be copied between programs, which involved a considerable performance overhead. It was also quite expensive. Nevertheless, Aleph proved that the basic system was sound, and went on to demonstrate computer clustering by copying the memory over an early Ethernet interface. Around this time a new generation of central processors (CPUs) were coming to market, offering 32 bit address spaces and (initially optional) support for a memory management unit (MMU). The MMU handled the instructions needed to implement a virtual memory system by keeping track of which pages of memory were in use by various programs. This offered a new solution to the port concept, using the copy on write mechanism provided by the virtual memory system. Instead of copying data between programs, all that had to be sent was the data needed to instruct the MMU to provide access to the same memory. This system would implement the interprocess communications system with dramatically higher performance. This concept was picked up at Carnegie Mellon, who adapted Aleph for the PERQ workstation and implemented it using copy on write. The port was successful, but the resulting Accent kernel was of limited practical use because it did not run existing software. Moreover, Accent was as tightly tied to PERQ as Aleph was to the Eclipse.

Mach was initially hosted as additional code written directly into the existing 4.2BSD kernel, allowing the team to work on the system long before it was complete. Work started with the already functional Accent IPC/port system, and moved on to the other key portions of the OS: tasks, threads, and virtual memory. As portions were completed various parts of the BSD system were re written to call into Mach, and a change to 4.3BSD was also made during this process. By 1986 the system was complete to the point of being able to run on its own on the DEC VAX. Although doing little of practical value, the goal of making a microkernel was realized. This was soon followed by versions on the IBM RT PC and for Sun Microsystems 68030 based workstations, proving the system's portability. By 1987 the list included the Encore Multimax and Sequent Balance machines, testing Mach's ability to run on multiprocessor systems. A public Release 1 was made that year, and Release 2 followed the next year. Throughout this time the promise of a "true" microkernel was not yet being delivered. These early Mach versions included the majority of 4.3BSD in the kernel, a system known as POE Server, resulting in a kernel that was actually larger than the UNIX it was based on. The idea, however, was to move the UNIX layer out of the kernel into user space, where it could be more easily worked on and even replaced outright. Unfortunately performance proved to be a major problem, and a number of architectural changes were made in order to solve this problem. Unwieldy UNIX licensing issues were also plaguing researchers, so this early effort to provide a non licensed UNIX like system environment continued to find use, well into the further development of Mach. The resulting Mach 3 was released in 1990, and generated intense interest. A small team had built Mach and ported it to a number of platforms, including complex multiprocessor systems which were causing serious problems for older style kernels. This generated considerable interest in the commercial market, where a number of companies were in the midst of considering changing hardware platforms. If the existing system could be ported to run on Mach, it would seem it would then be easy to change the platform underneath. Mach received a major boost in visibility when the Open Software Foundation (OSF) announced they would be hosting future versions of OSF/1 on Mach 2.5, and were investigating Mach 3 as well. Mach 2.5 was also selected for the NeXTSTEP system and a number of commercial multiprocessor vendors. Mach 3 led to a number of efforts to port other operating systems parts for the microkernel, including IBM's Workplace OS and several efforts by Apple to build a cross platform version of the classic Mac OS.

Mach was originally intended to be a replacement for classical monolithic UNIX, and for this reason contained many UNIX like ideas. For instance, Mach used a permissioning and security system patterned on UNIX's file system. Since the kernel was privileged (running in kernel space) over other OS servers and software, it was possible for malfunctioning or malicious programs to send it commands that would cause damage to the system, and for this reason the kernel checked every message for validity. Additionally most of the operating system functionality was to be located in user space programs, so this meant there needed to be some way for the kernel to grant these programs additional privileges, e. g. to directly access hardware. Some of Mach's more esoteric features were also based on this same IPC mechanism. For instance, Mach was able to support multi processor machines with ease. In a traditional kernel extensive work needs to be carried out to make it reentrant or interruptible, as programs running on different processors could call into the kernel at the same time. Under Mach, the bits of the operating system are isolated in servers, which are able to run, like any other program, on any processor. Although in theory the Mach kernel would also have to be reentrant, in practice this is not an issue because its response times are so fast it can simply wait and serve requests in turn. Mach also included a server that could forward messages not just between programs, but even over the network, which was an area of intense development in the late 1980s and early 1990s. Unfortunately, the use of IPC for almost all tasks turned out to have serious performance impact. Benchmarks on 1997 hardware showed that Mach 3.0 based UNIX single server implementations were about 50% slower than native UNIX. Study of the exact nature of the performance problems turned up a number of interesting facts. One was that the IPC itself was not the problem: there was some overhead associated with the memory mapping needed to support it, but this added only a small amount of time to making a call. The rest, 80% of the time being spent, was due to additional tasks the kernel was running on the messages. Primary among these was the port rights checking and message validity. In benchmarks on an 486DX 50, a standard UNIX system call took an average of 21μs to complete, while the equivalent operation with Mach IPC averaged 114μs. Only 18μs of this was hardware related; the rest was the Mach kernel running various routines on the message. Given a syscall that does nothing, a full round trip under BSD would require about 40μs, whereas on a user space Mach system it would take just under 500μs. When Mach was first being seriously used in the 2. x versions, performance was slower than traditional monolithic operating systems, perhaps as much as 25%. For example, getting the system time involves an IPC call to the user space server maintaining system clock. The caller first traps into the kernel, causing a context switch and memory mapping. The kernel then checks that the caller has required access rights and that the message is valid. If it is, there is another context switch and memory mapping to complete the call into the user space server. The process must then be repeated to return the results, adding up to a total of four context switches and memory mappings, plus two message verifications. This overhead rapidly compounds with more complex services, where there are often code paths passing through many servers. This was not the only source of performance problems. Another centered on the problems of trying to handle memory properly when physical memory ran low and paging had to occur. In the traditional monolithic operating systems the authors had direct experience with which parts of the kernel called which others, allowing them to fine tune their pager to avoid paging out code that was about to be used. Under Mach this was not possible because the kernel had no real idea what the operating system consisted of. Instead they had to use a single one size fits all solution, which added to the performance problems. Mach 3 attempted to address this problem by providing a simple pager, relying on user space pagers for better specialization. But this turned out to have little effect. In practice, any benefits it had were wiped out by the expensive IPC needed to call it in. Other performance problems were related to Mach's support for multiprocessor systems. From the mid 1980s to the early 1990s, commodity CPUs grew in performance at a rate of about 60% a year, but the speed of memory access grew at only 7% a year. This meant that the cost of accessing memory grew tremendously over this period, and since Mach was based on mapping memory around between programs, any "cache miss" made IPC calls slow.

IPC overhead is a major issue for Mach 3 systems. However, the concept of a multi server operating system is still promising, though it still requires some research. The developers have to be careful to isolate code into modules that do not call from server to server. For instance, the majority of the networking code would be placed in a single server, thereby minimizing IPC for normal networking tasks. Most developers instead stuck with the original POE concept of a single large server providing the operating system functionality. In order to ease development, they allowed the operating system server to run either in user space or kernel space. This allowed them to develop in user space and have all the advantages of the original Mach idea, and then move the debugged server into kernel space in order to get better performance. Several operating systems have since been constructed using this method, known as co location, among them Lites, MkLinux, OSF/1, and NeXTSTEP/OPENSTEP/macOS. The Chorus microkernel made this a feature of the basic system, allowing servers to be raised into the kernel space using built in mechanisms. Mach 4 attempted to address these problems, this time with a more radical set of upgrades. In particular, it was found that program code was typically not writable, so potential hits due to copy on write were rare. Thus it made sense to not map the memory between programs for IPC, but instead migrate the program code being used into the local space of the program. This led to the concept of "shuttles" and it seemed performance had improved, but the developers moved on with the system in a semi usable state. Mach 4 also introduced built in co location primitives, making it a part of the kernel itself. By the mid 1990s, work on microkernel systems was largely stagnant, although the market had generally believed that all modern operating systems would be microkernel based by the 1990s. The primary remaining widespread uses of the Mach kernel are Apple's macOS and its sibling iOS, which run atop a heavily modified hybrid Open Software Foundation Mach Kernel (OSFMK 7.3) called "XNU" also used in OSF/1. In XNU, the file systems, networking stacks, and process and memory management functions are implemented in the kernel; and file system, networking, and some process and memory management functions are invoked from user mode via ordinary system calls rather than message passing; XNU's Mach messages are used for communication between user mode processes, and for some requests from user mode code to the kernel and from the kernel to user mode servers.

Further analysis demonstrated that the IPC performance problem was not as obvious as it seemed. Recall that a single side of a syscall took 20μs under BSD the basis of macOS, iOS, iPadOS, watchOS, and tvOS