Revision as of 22:24, 19 March 2015 editCitation bot (talk | contribs)Bots5,404,403 editsm Alter: url. Add: author-separator, author pars. 1-5. Removed redundant parameters. You can use this bot yourself. Report bugs here.← Previous edit | Latest revision as of 06:21, 3 December 2024 edit undoKMaster888 (talk | contribs)3,103 edits style | ||
(230 intermediate revisions by more than 100 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Operating system microkernel}} | |||
{{multiple issues| | |||
{{ |
{{Use mdy dates|date=July 2024}} | ||
{{more footnotes|date=March 2015}} | |||
{{Expert-subject|WikiProject Computing|reason=Tone, original research, accuracy, verifying and inlining citations|date=March 2015}} | |||
}} | |||
{{Infobox software | {{Infobox software | ||
|name |
| name = Mach | ||
|logo |
| logo = | ||
|screenshot |
| screenshot = | ||
|caption |
| caption = | ||
|collapsible |
| collapsible = | ||
| other_names = | |||
|author = ] | |||
| author = | |||
|developer = | |||
| developer = ]<br /> ] | |||
|released = {{Start date and age|1985}} | |||
| released = {{Start date and age|1985}} | |||
|discontinued = | |||
| discontinued = | |||
|latest release version = 3.0 | |||
|latest release |
| latest release version = 3.0 | ||
| latest release date = {{Start date and age|1994}} | |||
|latest preview version |
| latest preview version = | ||
|latest preview date |
| latest preview date = <!-- {{Start date and age|YYYY|MM|DD}} --> | ||
|frequently updated |
| frequently updated = | ||
|programming language |
| programming language = | ||
|operating system |
| operating system = | ||
| platform = ], ], ], ], ], ] | |||
|platform = | |||
|size |
| size = | ||
|language |
| language = | ||
|status |
| status = | ||
|genre |
| genre = ] | ||
|license |
| license = | ||
|website |
| website = {{URL|https://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html|The Mach Project}} | ||
| Institution = | |||
}} | }} | ||
'''Mach''' {{ |
'''Mach''' ({{IPAc-en|m|ɑː|k}})<ref name="JyEdfG">{{cite dictionary|title=Mach: Define Mach at Dictionary.com|url=http://www.dictionary.com/browse/mach|dictionary=Dictionary.com|access-date=December 12, 2016}}</ref> is an ] developed at ] by ] and ] to support ] research, primarily ] and ]. Mach is often considered one of the earliest examples of a ]. However, not all versions of Mach are microkernels. Mach's derivatives are the basis of the operating system kernel in ] and of ]'s ] kernel used in ], ], ], ], and ]. | ||
The project at Carnegie Mellon ran from 1985 to 1994, ending with Mach 3.0, which is |
The project at Carnegie Mellon ran from 1985 to 1994,<ref name="HyeRgh">{{cite web|url=https://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html|title=CMU CS Project Mach Home Page}}</ref> ending with Mach 3.0, which is a true ]. Mach was developed as a replacement for the kernel in the ] version of ], not requiring a new operating system to be designed around it. Mach and its derivatives exist within several 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 ] management system was also adopted in 4.4BSD by the BSD developers at ],<ref name="JuRtBN">{{cite book|url=https://books.google.com/books?id=6rjd2ZxE1vYC&pg=PT200|title=The Design and Implementation of the 4.4 BSD Operating System|first1=Marshall Kirk|last1=McKusick|author-link1=Kirk McKusick|first2=Keith|last2=Bostic|author-link2=Keith Bostic (software engineer)|first3=Michael J.|last3=Karels|author-link3=Michael J. Karels|first4=John S.|last4=Quarterman|author-link4=John Quarterman|page=123|date=April 30, 1996|isbn=978-0-7686-8494-0|publisher=]}}</ref> and appears in modern BSD-derived Unix systems such as ]. | ||
Mach is the logical successor to Carnegie Mellon's ]. |
Mach is the logical successor to Carnegie Mellon's ]. Mach's lead developer Richard Rashid has been employed at ] since 1991; he founded the ] division. Co-founding Mach developer Avie Tevanian, was formerly head of software at ], then Chief Software Technology Officer at ] until March 2006.<ref name="IghTyn">{{cite news |url=http://blog.sfgate.com/techchron/2006/03/27/adios-avie/ |title=Adios Avie|author=Al Saracevic|publisher=The Technology Chronicles |date=March 27, 2006 |archive-url=https://web.archive.org/web/20111204041437/http://blog.sfgate.com/techchron/2006/03/27/adios-avie/ |archive-date=December 4, 2011 |url-status=dead}}</ref><ref name="HyeRgh" /> | ||
==History== | ==History== | ||
===Name=== | ===Name=== | ||
The developers rode bicycles to lunch through rainy Pittsburgh's mud puddles, and Tevanian joked the word "muck" could form a ] for their Multi-User (or Multiprocessor Universal) Communication Kernel. Italian CMU engineer Dario Giuse<ref>{{cite web | |||
|url = https://www.amia.org/about-amia/leadership/acmi-fellow/dario-giuse-phd-ms-facmi | |||
>{{cite web |url=http://www.osxbook.com/book/bonus/chapter1/ | |||
|title = Dario A. Giuse, PhD, MS, FACMI | |||
|title=A Technical History of Apple's Operating Systems |author=Singh, Amit | |||
|archive-url = https://web.archive.org/web/20200823012803/https://www.amia.org/about-amia/leadership/acmi-fellow/dario-giuse-phd-ms-facmi | |||
|date=2006-07-28 |page=103 |work= |publisher=osxbook.com |accessdate=18 March 2011}}</ref> | |||
|archive-date = August 23, 2020 | |||
|url-status = dead | |||
}}</ref> 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 {{IPA-all|mʌk}}. According to the ], he wrote "Mach". Rashid liked Giuse's spelling "Mach" so much that it prevailed.<ref name="singh">{{cite web |url=http://www.osxbook.com/book/bonus/chapter1/|title=A Technical History of Apple's Operating Systems |author=Singh, Amit|date=July 28, 2006 |publisher=osxbook.com |access-date=March 18, 2011 |archive-url=https://web.archive.org/web/20190827125517/http://www.osxbook.com/book/bonus/chapter1/ |archive-date=August 27, 2019 |url-status=dead}}</ref>{{rp|103}} | |||
=== |
===Unix pipes=== | ||
A key concept in the original Unix operating system is the idea of a ]. A pipe is an ] allowing data to be moved as an unstructured stream of bytes between programs. Using pipes, users can link together multiple programs to complete tasks, feeding data through several consecutive small programs. This contrasts with typical operating systems of the era, which require a single large program that can handle the entire task, or alternately, used files to pass data, which was resource expensive and time-consuming. | |||
Since Mach was designed as a "drop-in" replacement for the traditional UNIX kernel, this discussion focuses on what distinguishes Mach from UNIX. It became clear early{{weasel-inline|date=March 2015}} that UNIX's concept of everything-as-a-file might not be fast enough on modern systems, although some systems such as ] have tried this way. Nevertheless, those same developers lamented the loss of flexibility that the original concept offered. Another level of ] was sought that would make the system "work" again.{{Citation needed|date=January 2010}} | |||
Pipes were built on the underlying ] system. This system is, in turn, based on a model where drivers are expected to periodically "block" while they wait for tasks to complete. For instance, a ] might send a line of text to a ] and then have nothing to do until the printer completes printing that line. In this case, the driver indicates that it was blocked, and the operating system allows some other program to run until the printer indicates it is 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. | |||
The critical ] in UNIX was the ]. What was needed was a pipe-like concept that worked at a much more general level, allowing a broad variety of information to be passed between programs. Such a system did exist using ] (IPC): A pipe-like system that would move ''any'' information between two programs, as opposed to file-like information. While many systems, including most Unixes, had added various IPC implementations over the years, at the time these were generally special-purpose libraries only really useful for one-off tasks. | |||
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 ]s. The operating system's kernel and most core functionality was instead written in a single large program. When new functionality, such as ]ing, was added to the operating system, the size and complexity of the kernel grew, too. | |||
] started experimentation along these lines under the ] project, using an IPC system based on ]. Accent was a purely experimental system with many features, developed in an ad-hoc fashion over a period of time with changing research interests. Additionally, Accent's usefulness for research was limited because it was not UNIX-compatible, and UNIX was already the de facto standard for almost all operating system research. Finally, Accent was tightly coupled with the hardware platform on which it was developed, and at the time in the early 1980s it appeared there would soon be an explosion of new platforms, many of them ].{{Citation needed|date=December 2009}} | |||
===New concepts=== | |||
Mach started largely as an effort to produce a cleanly 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=]|year=1987| | |||
Unix pipes offered a conceptual system that could be used to build arbitrarily complex solutions out of small cooperating 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 was extremely important. There was a strong desire to model the kernel on the same basis of small cooperating programs. | |||
last1=Tevanian|first1=Avadis|authorlink=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| | |||
id = {{citeseerx|10.1.1.41.3458}} }}</ref><ref>{{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.toronto.edu/~demke/469F.06/Handouts/mach_usenix86.pdf | |||
}}</ref> | |||
* a "]" is an object consisting of a set of system resources that enable "threads" to run | |||
* a "]" is a single unit of execution, exists within a context of a task and shares the task's resources | |||
* a "]" is a protected ] for communication between tasks; tasks own send and receive rights to each port | |||
* "]" are collections of typed data objects, they can only be sent to ports—not specifically tasks or threads | |||
One of the first systems to use a pipe-like system underpinning the operating system was the ] developed at the ]. This introduced the concept of ports, which were essentially a ] implementation. In Aleph, the kernel 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 permitted 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 would otherwise require the machine to be restarted. The overall concept of a small kernel and external drivers became known as a microkernel. | |||
Mach developed on Accent's IPC concepts, but made the system much more UNIX-like in nature, even able to run UNIX programs with little or no modification. To do this, Mach introduced the concept of a ''port'', representing each endpoint of a two-way IPC. Ports had security and rights like files under UNIX, allowing 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 allow ] programs to handle things like interacting with hardware. | |||
Aleph was implemented on ] minicomputers and was tightly bound to them. This machine was far from ideal, since it required memory to be copied between programs, which resulted in considerable performance overhead. It was also quite expensive. Nevertheless, Aleph proved that the basic system was sound, and went on to demonstrate ]ing by copying the memory over an early ] interface. | |||
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 ] or ]s could move the drivers out of the microkernel. | |||
Around this time a new generation of ] (CPUs) were coming to market, offering a 32-bit ] and (initially optional) support for a ] (MMU). The MMU handled the instructions needed to implement a ] 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 ] (COW) mechanism provided by the virtual memory system. Instead of copying data between programs, all that was required was to instruct the MMU to provide access to that same memory. This system would implement the ]s (IPC) system with dramatically higher performance. | |||
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 ]. 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 maintaining the "utilities" and scheduling their access to hardware. | |||
This concept was picked up at Carnegie-Mellon, who adapted Aleph for the ] 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. | |||
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 known as a '']'' or '']''. The program uses a ] to place data in a well known location in memory and then causes a '']'', a type of error. When the system is first started the kernel is set up to be the "handler" of all faults, so when the program causes a fault the kernel takes over, examines the information passed to it, and then carries out the instructions. | |||
===Mach=== | |||
Under Mach, the IPC system was used for this role instead. In order 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 the messages were triggered by system calls as they would be on other kernels, under Mach that was pretty much all the kernel did—handling the actual request would be up to some other program. | |||
The major change between these experimental kernels and Mach was the decision to make a version of the existing ] kernel re-implemented on the Accent message-passing concepts. Such a kernel would be binary compatible with existing ] 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 ]-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=]|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> | |||
The use of IPC for message passing benefited support for threads and concurrency. Since tasks consisted of multiple threads, and it was the code in the threads that used the IPC mechanism, Mach was able to freeze and unfreeze threads while the message was handled. This allowed the system to be distributed over multiple processors, either 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 don't try to write to the same memory from different processors. Under Mach this was well defined and easy to implement; it was the very process of accessing that memory, the ports, that was made a first-class citizen of the system. | |||
* a "]" is a set of system resources that produce "threads" to run | |||
* a "]" is a single unit of execution, existing within the context of a task and shares the task's resources | |||
* a "]" is a protected ] for communication between tasks; tasks own send and receive rights (permissions) to each port. | |||
* "]" 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 ] programs to handle things such as controlling hardware. | |||
The IPC system initially had performance problems, so a few strategies were developed to minimize the impact. Like its predecessor, ], 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 ] (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 "]". | |||
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 ] or ]s could move the drivers out of the microkernel. | |||
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 allowed 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. | |||
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 ]. 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 '']'' or '']''. The program uses a ] to place data in a well known location in memory and then causes a '']'', 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 ]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 ] (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 "]". | |||
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 ] 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. | 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 ] 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: | 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>(, )</ref> | |||
: 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. (, ) | |||
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. | 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. | ||
===Development=== | ===Development=== | ||
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 |
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 ]. Although doing little of practical value, the goal of making a microkernel was realized. This was soon followed by versions on the ] and for ] ]-based workstations, proving the system's portability. By 1987 the list included the |
By 1986 the system was complete to the point of being able to run on its own on the ]. Although doing little of any practical value, the goal of making a microkernel was realized. This was soon followed by versions on the ] and for ] ]-based workstations, proving the system's portability. By 1987 the list included the Encore Multimax and ] 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 |
Throughout this time the promise of a "true" microkernel had not yet been delivered. These early Mach versions included the majority of 4.3BSD in the kernel, a system known as a 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 also plagued 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 |
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 considering changing hardware platforms. If the existing system could be ported to run on Mach, it seemed it would then be easy to change the platform underneath. | ||
Mach received a major boost in visibility when the ] (OSF) announced they would be hosting future versions of ] on Mach 2.5, and were investigating Mach 3 as well. Mach 2.5 was also selected for the ] 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 ]'s ] and several efforts by ] to build a cross-platform version of the ]. | Mach received a major boost in visibility when the ] (OSF) announced they would be hosting future versions of ] on Mach 2.5, and were investigating Mach 3 as well. Mach 2.5 was also selected for the ] 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 ]'s ] and several efforts by ] to build a cross-platform version of the ].<ref name=":5" /> Support for running DOS applications in a Mach 3.0 environment was demonstrated by researchers, following on from earlier work running the classic Mac OS and ] under Mach 2.5.<ref name="usenixmach1991_malan">{{ cite journal | url=https://archive.org/details/1991-proceedings-mach-symposium-monterey/page/27/mode/1up | title=DOS as a Mach 3.0 Application | journal=Proceedings of the Usenix Mach Symposium | publisher=Usenix Association | date=November 1991 | access-date=January 19, 2024 | first1=Gerald | last1=Malan | first2=Richard | last2=Rashid | first3=David | last3=Golub | first4=Robert | last4=Baron | pages=27–40 }}</ref> | ||
===Performance issues=== | ===Performance issues=== | ||
Mach was originally intended to be a replacement for classical monolithic UNIX, and for this reason contained many UNIX-like ideas. For instance, Mach |
Mach was originally intended to be a replacement for classical monolithic UNIX, and for this reason contained many UNIX-like ideas. For instance, Mach provided a permissions and security system similar to that used by 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 ] 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 |
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 ] 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 ] single-server implementations were about 50% slower than native UNIX.<ref name="condict94">{{ |
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 ] single-server implementations were about 50% slower than native UNIX.<ref name="condict94">{{cite web |author1=M. Condict |author2=D. Bolinger |author3=E. McManus |author4=D. Mitchell |author5=S. Lewontin |title=Microkernel modularity with integrated kernel performance |url=http://www.cs.utah.edu/~lepreau/osdi94/condict/abstract.html |date=April 1994 |access-date=February 19, 2019 |archive-date=June 19, 2017 |archive-url=https://web.archive.org/web/20170619131352/http://www.cs.utah.edu/~lepreau/osdi94/condict/abstract.html |url-status=dead}}</ref><ref name="hartig97p67">{{cite conference |doi= 10.1145/269005.266660|title=The performance of μ-kernel-based systems |conference= 16th ACM symposium on Operating systems principles (SOSP'97)|location=Saint-Malo, France |date=October 1997 |volume= 31 |isbn=0-89791-916-5 |issue= 5 |url=http://os.inf.tu-dresden.de/pubs/sosp97/|page=67 |first1=Hermann |last1=Härtig |first2=Michael |last2=Hohmuth |first3=Jochen |last3=Liedtke |first4=Sebastian |last4=Schönberg |first5=Jean |last5=Wolter |author-link3=Jochen Liedtke|doi-access=free }}</ref> | ||
Study of the exact nature of the performance problems turned up a number of interesting facts. One was that the IPC 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 ]DX-50, a standard UNIX system call took an average of 21] 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.<ref name="liedtke93">{{cite conference |author= Jochen Liedtke |title= Improving IPC by Kernel Design |book-title= Proceedings of the 14th ACM Symposium on Operating System Principles (SOSP) |year=1993 |isbn=978-0-89791-632-5 |author-link=Jochen Liedtke |citeseerx=10.1.1.55.9939 |doi=10.1145/168619.168633}}</ref> 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. | |||
Studies showed the vast majority of this performance hit, 73% by one measure, was due to the overhead of the IPC.{{Citation needed|date=February 2007}} And this was measured on a system with a single large server providing the operating system; breaking the operating system down further into smaller servers would only make the problem worse. It appeared the goal of a collection-of-servers was simply not possible. | |||
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%.<ref name="JyEdfG" /> This cost was not considered particularly worrying, however, because the system was also offering multi-processor support and easy portability. Many felt this was an expected and acceptable cost to pay. When Mach 3 attempted to move most of the operating system into user-space, the overhead became higher still: benchmarks between Mach and ] on a MIPS ] showed a performance hit as great as 67% on some workloads.<ref name="chen93">{{cite journal |title= The impact of operating system structure on memory system performance |last1= Chen |first1= J B |last2= Bershad |first2= B N |journal= ACM SIGOPS Operating Systems Review |volume= 27 |page= 133 |year= 1993 |citeseerx= 10.1.1.52.4651 |issue= 5|doi= 10.1145/173668.168629}}</ref> | |||
Many attempts were made to improve the performance of Mach and Mach-like microkernels, but by the mid-1990s much of the early intense interest had died. The concept of an operating system based on IPC appeared to be dead, the idea itself flawed.{{Citation needed|date=February 2007}} | |||
For example, getting the system time involves an IPC call to the user-space server maintaining ]. 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. | |||
In fact, further 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 ]DX-50, a standard UNIX system call took an average of 21] 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.<ref name="liedtke93">{{Cite journal| author = Jochen Liedtke | title = Improving IPC by Kernel Design | journal = Proceedings of the 14th ACM Symposium on Operating System Principles (SOSP) | year=1993 | isbn=0-89791-632-8 |authorlink=Jochen Liedtke}}</ref> 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. | |||
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. | |||
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%.{{Citation needed|date=February 2007}} This cost was not considered particularly worrying, however, because the system was also offering multi-processor support and easy portability. Many felt this was an expected and acceptable cost to pay. When Mach 3 attempted to move most of the operating system into user-space, the overhead became higher still: benchmarks between Mach and ] on a MIPS ] showed a performance hit as great as 67% on some workloads.<ref name="chen93">{{Cite journal | title = The impact of operating system structure on memory system performance | last1 = Chen | first1 = J B | last2 = Bershad | first2 = B N | journal = ACM SIGOPS Operating Systems Review | volume = 27 | pages = 133 | year = 1993 | publisher = ] | id = {{citeseerx|10.1.1.52.4651}} | issue = 5 }}</ref> | |||
For example, getting the system time involves an IPC call to the user-space server maintaining ]. 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 does, 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 wasn't 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 that 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 ] 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. | Other performance problems were related to Mach's support for ] 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. | ||
Regardless of the advantages of the Mach approach, these sorts of real-world performance hits were simply not acceptable. As other teams found the same sorts of results, the early Mach enthusiasm quickly disappeared. After a short time many in the development community seemed to conclude that the entire concept of using IPC as the basis of an operating system was inherently flawed.{{Citation needed|date=February 2007}} | |||
===Potential solutions=== | ===Potential solutions=== | ||
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. | 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 ], ], ] and NeXTSTEP/OPENSTEP/ |
Most developers instead stuck with the original POE concept of a single large server providing the operating system functionality.<ref name="c6CLw">{{cite web|url=https://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/poe_notes.ps|title=A Brief Description of the POE server|author=Mary Thompson|date=April 14, 1994}}</ref> 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 ], ], ], and NeXTSTEP/OPENSTEP/macOS. The ] 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 |
Mach 4 attempted to address these problems 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. | ||
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 |
By the mid-1990s, work on microkernel systems was largely stagnant, although the market ] 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 ] Open Software Foundation Mach Kernel (OSFMK 7.3) called "]"<ref name="wwdc-2000-session-106">{{cite AV media|url=https://www.youtube.com/watch?v=ggnFoDqzGMU |archive-url=https://ghostarchive.org/varchive/youtube/20211211/ggnFoDqzGMU| archive-date=December 11, 2021 |url-status=live|author=Jim Magee|title=WWDC 2000 Session 106 - Mac OS X: Kernel|minutes=14}}{{cbignore}}</ref> also used in OSF/1.<ref name=":5">{{cite conference |url=https://pdfs.semanticscholar.org/03ac/1296f530719497b49d7580b55a2d9b8353ab.pdf|archive-url=https://web.archive.org/web/20170822053715/https://pdfs.semanticscholar.org/03ac/1296f530719497b49d7580b55a2d9b8353ab.pdf|archive-date=August 22, 2017|url-status=dead|title=A Trusted, Scalable, Real-Time Operating System Environment |conference=1994 IEEE Dual-Use Technologies and Applications Conference |author=Douglas M. Wells|year=1994 |s2cid=5205380}}</ref> 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 ]s rather than message passing;<ref name="m9l5s">{{cite web|url=https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html#//apple_ref/doc/uid/TP30000905-CH1g-CACDAEDC|title=Kernel Architecture Overview|work=Kernel Programming Guide|publisher=]|date=August 8, 2013|access-date=March 3, 2015}}</ref><ref name="HytGhy">{{cite web|url=https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/boundaries/boundaries.html#//apple_ref/doc/uid/TP30000905-CH217-BEHJDFCA|title=Boundary Crossings|work=Kernel Programming Guide|publisher=Apple Inc.|date=August 8, 2013|access-date=March 3, 2015}}</ref> 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. | ||
===Second-generation microkernels=== | ===Second-generation microkernels=== | ||
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 and 114μs on Mach running on the same system. Of the 114, 11 were due to the context switch, identical to BSD. An additional 18 were used by the MMU to map the message between user-space and kernel space. This adds up to only |
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<ref name="JuRtBN" /> and 114μs on Mach running on the same system.<ref name="HyeRgh" /> Of the 114, 11 were due to the context switch, identical to BSD.<ref name="hartig97p67" /> An additional 18 were used by the MMU to map the message between user-space and kernel space.<ref name="JuRtBN" /> This adds up to only 29μs, longer than a traditional syscall, but not by much. | ||
The rest, the majority of the actual problem, was due to the kernel performing tasks such as checking the message for port access rights. While it would seem this is an important security concern, in fact, it only makes sense in a UNIX-like system. For instance, a single-user operating system running a ] or ] might not need any of these features, and this is exactly the sort of system where Mach's pick-and-choose operating system would be most valuable. Likewise Mach caused problems when memory had been moved by the operating system, another task that only really makes sense if the system has more than one address space. ] and the early ] |
The rest, the majority of the actual problem, was due to the kernel performing tasks such as checking the message for port access rights.<ref name="singh" /> While it would seem this is an important security concern, in fact, it only makes sense in a UNIX-like system. For instance, a single-user operating system running a ] or ] might not need any of these features, and this is exactly the sort of system where Mach's pick-and-choose operating system would be most valuable. Likewise Mach caused problems when memory had been moved by the operating system, another task that only really makes sense if the system has more than one address space. ] and the early ] have a ] shared by all programs, so under these systems the mapping did not provide any benefits. | ||
These realizations led to a series of |
These realizations led to a series of second generation microkernels, which further reduced the complexity of the system and placed almost all functionality in the user space. For instance, the ] (version 2) includes only seven system calls and uses 12k of memory,<ref name="JuRtBN" /> whereas Mach 3 includes about 140 functions and uses about 330k of memory.<ref name="JuRtBN" /> IPC calls under L4 on a 486DX-50 take only 5μs,<ref name="HytGhy" /> faster than a UNIX syscall on the same system, and over 20 times as fast as Mach. Of course this ignores the fact that L4 is not handling permissioning or security; but by leaving this to the user-space programs, they can select as much or as little overhead as they require. | ||
The |
The potential performance gains of L4 are tempered by the fact that the user-space applications will often have to provide many of the functions formerly supported by the kernel. In order to test the end-to-end performance, MkLinux in co-located mode was compared with an L4 port running in user-space. L4 added about 5%–10% overhead,<ref name="hartig97p67" /> compared to Mach's 29%.<ref name="hartig97p67" /> | ||
==Software based on Mach== | |||
These newer microkernels have revitalized the industry as a whole, and projects such as the ] have received new attention as a result.{{citation needed|date=March 2015}} | |||
The following is a list of operating system kernels derived from Mach and operating systems with kernels derived from Mach: | |||
{{Div col}} | |||
== Software based on Mach == | |||
* ] | |||
The following is a list of operating system kernels which are derived from Mach. | |||
{{div col | columns=2}} | |||
* ]/] | |||
* ] | * ] | ||
* ] | * ] | ||
* ] | * ]'s Mach386 | ||
* ] | * ] | ||
* ] | * ] | ||
* ] | * ] | ||
* ] | * ] (Digital UNIX/]) | ||
* ] | * ] | ||
* ] | * ] | ||
* The ] kernel for ],<ref name="Iq2Jm">{{Citation |title= Mach Overview |last= Apple Inc. |url= https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html |date=February 26, 2013}}</ref> the basis of ], ], ], ], and ] | |||
* ] | |||
{{Div col end}} | |||
* ] and ], the basis of ] and ] | |||
{{div col end}} | |||
== |
==See also== | ||
* ] | * ] | ||
* ] | * ] | ||
Line 175: | Line 162: | ||
* ] | * ] | ||
== |
==References== | ||
{{ |
{{reflist}} | ||
==External links== | ==External links== | ||
* |
* {{Official website|https://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html}}, Carnegie Mellon University CS Project Mach Home Page | ||
* |
* – Appendix to ''Operating System Concepts'' (8th ed) by Avi Silberschatz, Peter Baer Galvin and Greg Gagne | ||
* | * | ||
* |
* – Contains numerous performance measurements, including those quoted in the article | ||
* |
* – Contains an excellent performance comparison of Linux running as a monokernel, on Mach 3 and on L4 | ||
* - Browsable version of the Mach Kernel source code on the FreeBSD/Linux kernel cross reference site | * - Browsable version of the Mach Kernel source code on the FreeBSD/Linux kernel cross reference site | ||
* | * | ||
* {{cite web|url=http://www.db.opengroup.org/ar/technologies/mk-dbleplus/white_paper.htm|title=MK++: A High Performance, High Assurance Microkernel|last=Loepere|first=Keith|access-date=August 22, 2017|archive-date=August 22, 2017|archive-url=https://web.archive.org/web/20170822055033/http://www.db.opengroup.org/ar/technologies/mk-dbleplus/white_paper.htm|url-status=dead}} | |||
{{Carnegie Mellon}} | |||
{{FOSS}} | |||
{{Mach-like}} | {{Mach-like}} | ||
{{Microkernel}} | |||
{{Carnegie Mellon University}} | |||
{{FOSS}} | |||
{{DEFAULTSORT:Mach (Kernel)}} | {{DEFAULTSORT:Mach (Kernel)}} | ||
] | |||
] | ] | ||
] | |||
] | ] |
Latest revision as of 06:21, 3 December 2024
Operating system microkernel
Developer(s) | Richard Rashid Avie Tevanian |
---|---|
Initial release | 1985; 39 years ago (1985) |
Stable release | 3.0 / 1994; 30 years ago (1994) |
Platform | IA-32, x86-64, MIPS, ARM32, Aarch64, m88k |
Type | Microkernel |
Website | The Mach Project |
Mach (/mɑːk/) is an operating system 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, not requiring a new operating system to be designed around it. Mach and its derivatives exist within several 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. Mach's lead developer Richard Rashid has been employed at Microsoft since 1991; he founded the Microsoft Research division. Co-founding Mach developer Avie Tevanian, was formerly head of software at NeXT, then Chief Software Technology Officer at Apple Inc. until March 2006.
History
Name
The developers rode bicycles to lunch through rainy Pittsburgh's mud puddles, and Tevanian joked the word "muck" could form a backronym for their Multi-User (or Multiprocessor Universal) Communication Kernel. Italian CMU engineer Dario Giuse 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 IPA: [mʌk]. According to the Italian alphabet, he wrote "Mach". Rashid liked Giuse's spelling "Mach" so much that it prevailed.
Unix pipes
A key concept in the original Unix operating system is the idea of a pipe. A pipe is an abstraction allowing data to be moved as an unstructured stream of bytes between programs. Using pipes, users can link together multiple programs to complete tasks, feeding data through several consecutive small programs. This contrasts with typical operating systems of the era, which require a single large program that can 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 is, in turn, based on a model where drivers are expected to periodically "block" while they wait 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 completes printing that line. In this case, the driver indicates that it was blocked, and the operating system allows some other program to run until the printer indicates it is 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.
New concepts
Unix pipes offered a conceptual system that could be used to build arbitrarily complex solutions out of small cooperating 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 was extremely important. There was a strong desire to model the kernel on the same basis of small cooperating 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 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 permitted 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 would otherwise require the machine to be restarted. The overall 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 resulted in 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 a 32-bit address space 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 (COW) mechanism provided by the virtual memory system. Instead of copying data between programs, all that was required was to instruct the MMU to provide access to that same memory. This system would implement the interprocess communications (IPC) 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
The major change between these experimental kernels and Mach was the decision to make a version of the existing 4.2BSD kernel re-implemented on the Accent message-passing concepts. Such a kernel would be binary compatible with existing 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.
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:
- a "task" is a set of system resources that produce "threads" to run
- a "thread" is a single unit of execution, existing within the context of a task and shares the task's resources
- a "port" is a protected message queue for communication between tasks; tasks own send and receive rights (permissions) to each port.
- "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 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 or exokernels 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 trap. The program uses a library to place data in a well known location in memory and then causes a 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 citizens 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 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.
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.
Development
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 any 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 had not yet been delivered. These early Mach versions included the majority of 4.3BSD in the kernel, a system known as a 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 also plagued 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 considering changing hardware platforms. If the existing system could be ported to run on Mach, it seemed 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. Support for running DOS applications in a Mach 3.0 environment was demonstrated by researchers, following on from earlier work running the classic Mac OS and MultiFinder under Mach 2.5.
Performance issues
Mach was originally intended to be a replacement for classical monolithic UNIX, and for this reason contained many UNIX-like ideas. For instance, Mach provided a permissions and security system similar to that used by 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 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%. This cost was not considered particularly worrying, however, because the system was also offering multi-processor support and easy portability. Many felt this was an expected and acceptable cost to pay. When Mach 3 attempted to move most of the operating system into user-space, the overhead became higher still: benchmarks between Mach and Ultrix on a MIPS R3000 showed a performance hit as great as 67% on some workloads.
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.
Potential solutions
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 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.
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.
Second-generation microkernels
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 and 114μs on Mach running on the same system. Of the 114, 11 were due to the context switch, identical to BSD. An additional 18 were used by the MMU to map the message between user-space and kernel space. This adds up to only 29μs, longer than a traditional syscall, but not by much.
The rest, the majority of the actual problem, was due to the kernel performing tasks such as checking the message for port access rights. While it would seem this is an important security concern, in fact, it only makes sense in a UNIX-like system. For instance, a single-user operating system running a cell phone or robot might not need any of these features, and this is exactly the sort of system where Mach's pick-and-choose operating system would be most valuable. Likewise Mach caused problems when memory had been moved by the operating system, another task that only really makes sense if the system has more than one address space. DOS and the early Mac OS have a single large address space shared by all programs, so under these systems the mapping did not provide any benefits.
These realizations led to a series of second generation microkernels, which further reduced the complexity of the system and placed almost all functionality in the user space. For instance, the L4 kernel (version 2) includes only seven system calls and uses 12k of memory, whereas Mach 3 includes about 140 functions and uses about 330k of memory. IPC calls under L4 on a 486DX-50 take only 5μs, faster than a UNIX syscall on the same system, and over 20 times as fast as Mach. Of course this ignores the fact that L4 is not handling permissioning or security; but by leaving this to the user-space programs, they can select as much or as little overhead as they require.
The potential performance gains of L4 are tempered by the fact that the user-space applications will often have to provide many of the functions formerly supported by the kernel. In order to test the end-to-end performance, MkLinux in co-located mode was compared with an L4 port running in user-space. L4 added about 5%–10% overhead, compared to Mach's 29%.
Software based on Mach
The following is a list of operating system kernels derived from Mach and operating systems with kernels derived from Mach:
- GNU Hurd
- Lites
- MkLinux
- mtXinu's Mach386
- MachTen
- MacMach
- NeXTSTEP
- OSF/1 (Digital UNIX/Tru64 UNIX)
- Workplace OS
- UNICOS MAX
- The XNU kernel for Darwin, the basis of macOS, iOS, iPadOS, watchOS, and tvOS
See also
References
- ^ "Mach: Define Mach at Dictionary.com". Dictionary.com. Retrieved December 12, 2016.
- ^ "CMU CS Project Mach Home Page".
- ^ McKusick, Marshall Kirk; Bostic, Keith; Karels, Michael J.; Quarterman, John S. (April 30, 1996). The Design and Implementation of the 4.4 BSD Operating System. Addison-Wesley. p. 123. ISBN 978-0-7686-8494-0.
- ^ Al Saracevic (March 27, 2006). "Adios Avie". The Technology Chronicles. Archived from the original on December 4, 2011.
- "Dario A. Giuse, PhD, MS, FACMI". Archived from the original on August 23, 2020.
- ^ Singh, Amit (July 28, 2006). "A Technical History of Apple's Operating Systems". osxbook.com. Archived from the original on August 27, 2019. Retrieved March 18, 2011.
- Tevanian, Avadis; Rashid, Richard F.; Golub, David B.; Black, David L.; Cooper, Eric; Young, Michael W. (1987). Mach Threads and the Unix Kernel: The Battle for Control. USENIX Summer Conference. USENIX. pp. 185–197. CiteSeerX 10.1.1.41.3458.
- Accetta, Mike; Baron, Robert; Bolosky, William; Golub, David; Rashid, Richard; Tevanian, Avadis; Young, Michael (1986). Mach: A New Kernel Foundation for UNIX Development (PDF). USENIX Summer Conference. USENIX. Archived from the original (PDF) on July 6, 2017. Retrieved April 4, 2015.
- (Appendix B, Operating System Concepts)
- ^ Douglas M. Wells (1994). A Trusted, Scalable, Real-Time Operating System Environment (PDF). 1994 IEEE Dual-Use Technologies and Applications Conference. S2CID 5205380. Archived from the original (PDF) on August 22, 2017.
- Malan, Gerald; Rashid, Richard; Golub, David; Baron, Robert (November 1991). "DOS as a Mach 3.0 Application". Proceedings of the Usenix Mach Symposium. Usenix Association: 27–40. Retrieved January 19, 2024.
- M. Condict; D. Bolinger; E. McManus; D. Mitchell; S. Lewontin (April 1994). "Microkernel modularity with integrated kernel performance". Archived from the original on June 19, 2017. Retrieved February 19, 2019.
- ^ Härtig, Hermann; Hohmuth, Michael; Liedtke, Jochen; Schönberg, Sebastian; Wolter, Jean (October 1997). The performance of μ-kernel-based systems. 16th ACM symposium on Operating systems principles (SOSP'97). Vol. 31. Saint-Malo, France. p. 67. doi:10.1145/269005.266660. ISBN 0-89791-916-5.
- Jochen Liedtke (1993). "Improving IPC by Kernel Design". Proceedings of the 14th ACM Symposium on Operating System Principles (SOSP). CiteSeerX 10.1.1.55.9939. doi:10.1145/168619.168633. ISBN 978-0-89791-632-5.
- Chen, J B; Bershad, B N (1993). "The impact of operating system structure on memory system performance". ACM SIGOPS Operating Systems Review. 27 (5): 133. CiteSeerX 10.1.1.52.4651. doi:10.1145/173668.168629.
- Mary Thompson (April 14, 1994). "A Brief Description of the POE server".
- Jim Magee. WWDC 2000 Session 106 - Mac OS X: Kernel. 14 minutes in. Archived from the original on December 11, 2021.
- "Kernel Architecture Overview". Kernel Programming Guide. Apple Inc. August 8, 2013. Retrieved March 3, 2015.
- ^ "Boundary Crossings". Kernel Programming Guide. Apple Inc. August 8, 2013. Retrieved March 3, 2015.
- Apple Inc. (February 26, 2013), Mach Overview
External links
- Official website, Carnegie Mellon University CS Project Mach Home Page
- The Mach System – Appendix to Operating System Concepts (8th ed) by Avi Silberschatz, Peter Baer Galvin and Greg Gagne
- A comparison of Mach, Amoeba, and Chorus
- Towards Real Microkernels – Contains numerous performance measurements, including those quoted in the article
- The Performance of µ-Kernel-Based Systems – Contains an excellent performance comparison of Linux running as a monokernel, on Mach 3 and on L4
- Mach kernel source code - Browsable version of the Mach Kernel source code on the FreeBSD/Linux kernel cross reference site
- Unraveling the Mac OS X Microkernel Myth
- Loepere, Keith. "MK++: A High Performance, High Assurance Microkernel". Archived from the original on August 22, 2017. Retrieved August 22, 2017.
Mach and Mach-like operating systems | |
---|---|
Microkernels-nanokernels | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Kernels |
| ||||||||||||||||||||||||
Operating systems |
| ||||||||||||||||||||||||
Frameworks, kits |
| ||||||||||||||||||||||||
Developers | |||||||||||||||||||||||||
|
Free and open-source software | |||
---|---|---|---|
General | |||
Software packages | |||
Community | |||
Organisations | |||
Licenses |
| ||
Challenges | |||
Related topics | |||