Minix 3
Open source | |
Initial release | 24 October 2005 |
---|---|
Latest release | 3.3.0 / September 16, 2014 |
Latest preview | 3.4.0 rc6 / May 9, 2017 |
Repository | |
Marketing target | ARM |
Kernel type | Microkernel |
Userland | Minix, NetBSD |
Default user interface | ash |
License | 2005: BSD-3-Clause[a][1] Original: BSD-3-Clause |
Preceded by | Minix 1.0, 1.5 and 2.0 |
Official website | www |
Minix 3 is a small, Unix-like operating system. It is published under a BSD-3-Clause[a] license and is a successor project to the earlier versions, Minix 1 and 2.[1]
The project's main goal is for the system to be
As of 2017[update], Minix 3 supports
Minix 3 is believed to have inspired the
Goals of the project
Reflecting on the nature of monolithic kernel based systems, where a driver (which has, according to Minix creator Tanenbaum, approximately 3–7 times as many bugs as a usual program)[17] can bring down the whole system,[18] Minix 3 aims to create an operating system that is a "reliable, self-healing, multiserver Unix clone".[19]
To achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system named the reincarnation server. If a driver fails to respond to pings from this server, it is shut down and replaced by a fresh copy of the driver.
In a monolithic system, a bug in a driver can easily crash the whole kernel. This is far less likely to occur in Minix 3.[20]
History
Version | Release date | Description |
---|---|---|
3.1.0 (OSDI3) |
2005-10-18 |
|
3.1.1 (SOSP) |
2005-10-24 |
|
3.1.2 | 2006-04-18 |
|
3.1.2a | 2006-05-29 |
|
3.1.3 | 2007-04-13 |
|
3.1.3a | 2007-06-08 |
|
3.1.4 | 2009-06-09 |
|
3.1.5 | 2009-11-05 |
|
3.1.6 | 2010-02-08 |
|
3.1.7 | 2010-06-16 |
|
3.1.8 | 2010-10-04 | |
3.2.0 | 2012-02-29 |
|
3.2.1 | 2013-02-21 |
|
3.3.0[27] | 2014-09-15 |
|
3.4.0 rc6 | 2017-05-09 | X11 is now part of the operating system. |
|
Minix 3 was publicly announced on 24 October 2005 by Andrew Tanenbaum during his keynote speech on top of the Association for Computing Machinery (ACM) Symposium Operating Systems Principles conference. Although it still serves as an example for the new edition of Tanenbaum and Woodhull's textbook, it is comprehensively redesigned to be "usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability."
Initially released under the same BSD-3-Clause license that Minix was licensed under since 2000.[23][24] In late 2005, the copyright owner was changed and a fourth clause was added.[1][25][28]
Reliability policies
One of the main goals of Minix 3 is reliability. Below, some of the more important principles that enhance its reliability are discussed.
Reduce kernel size
Monolithic operating systems such as Linux and FreeBSD and hybrids like Windows have millions of lines of kernel code. In contrast, Minix 3 has about 6,000 lines of executable kernel code,[29] which can make problems easier to find in the code.
Cage the bugs
In monolithic kernels, device drivers reside in the kernel. Thus, when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. One bad line of code in a driver can bring down the system.
Instead, in Minix 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform arbitrary input/output (I/O), or write to absolute memory. They must make kernel calls for these services and the kernel checks each call for authority.
Limit drivers' memory access
In monolithic kernels, a driver can write to any word of memory and thus accidentally corrupt user programs.
In Minix 3, when a user expects data from, for example, the file system, it builds a descriptor telling who has access and at what addresses. It then passes an index to this descriptor to the file system, which may pass it to a driver. The file system or driver then asks the kernel to write via the descriptor, making it impossible for them to write to addresses outside the buffer.
Survive bad pointers
Dereferencing a bad pointer within a driver will crash the driver process, but will have no effect on the system as a whole. The reincarnation server will restart the crashed driver automatically. Users will not notice recovery for some drivers (e.g., disk and network) but for others (e.g., audio and printer), they might. In monolithic kernels, dereferencing a bad pointer in a driver normally leads to a system crash.
Tame infinite loops
If a driver gets into an infinite loop, the scheduler will gradually lower its priority until it becomes idle. Eventually the reincarnation server will see that it is not responding to status requests, so it will kill and restart the looping driver. In a monolithic kernel, a looping driver could hang the system.
Limit damage from buffer overflows
Minix 3 uses fixed-length messages for internal communication, which eliminates certain
Restrict access to kernel functions
Device drivers obtain
Restrict access to I/O ports
The kernel also maintains a table telling which
Restrict communication with OS components
Not every driver and server needs to communicate with every other driver and server. Accordingly, a per-process bit map determines which destinations each process may send to.
Reincarnate dead or sick drivers
A special process, called the reincarnation server, periodically pings each device driver. If the driver dies or fails to respond correctly to pings, the reincarnation server automatically replaces it with a fresh copy. Detecting and replacing non-functioning drivers is automatic, with no user action needed. This feature does not work for disk drivers at present, but in the next release the system will be able to recover even disk drivers, which will be shadowed in random-access memory (RAM). Driver recovery does not affect running processes.
Integrate interrupts and messages
When an interrupt occurs, it is converted at a low level to a notification sent to the appropriate driver. If the driver is waiting for a message, it gets the interrupt immediately; otherwise it gets the notification the next time it does a RECEIVE
to get a message. This scheme eliminates nested interrupts and makes driver programming easier.
Architecture
As can be seen, at the bottom level is the
At the next level up, there are the
At the next level there are the servers. This is where nearly all the operating system functionality is located. User processes obtain file service, for example, by sending messages to the file server to open, close, read, and write files. In turn, the file server gets disk I/O performed by sending messages to the disk driver, which controls the disk.
One of the key servers is the reincarnation server. Its job is to poll all the other servers and drivers to check on their health periodically. If a component fails to respond correctly, or exits, or gets into an infinite loop, the reincarnation server (which is the parent process of the drivers and servers) kills the faulty component and replaces it with a fresh copy. In this way the system is automatically made self-healing without interfering with running programs.
Currently the reincarnation server, the process server, and the microkernel are part of the trusted computing base. If any of them fail, the system crashes. Nevertheless, reducing the trusted computing base from 3-5 million lines of code, as in Linux and Windows systems, to about 20,000 lines greatly enhances system reliability.[citation needed]
Differences between Minix 3 and prior versions
Minix 1.0, 1.5, and 2.0 were developed as tools to help people learn about the design of operating systems.
Minix 1.0, released in 1987, was 12,000 lines of
Minix 1.5, released in 1991, included support for
Minix 2.0, released in 1997, was only available for the
Minix 3 does the same, and provides a modern operating system with many newer tools and many Unix applications.[30] Prof. Tanenbaum once said:
Please be aware that MINIX 3 is not your grandfather's MINIX ... MINIX 1 was written as an educational tool ... MINIX 3 is that plus a start at building a highly reliable, self-healing, bloat-free operating system ... MINIX 1 and MINIX 3 are related in the same way as Windows 3.1 and Windows XP are: same first name.[19]
Many improvements have also been made in the structure of the kernel since the Minix 2 release, making the system more reliable.
Minix 3.2.0 was released in February 2012. This version has many new features, including the
Minix 3.3.0 was released in September 2014. This release is the first version to support the
Mascot
Rocky Raccoon is the mascot of Minix 3.[33]
MINIXCon
MINIXCon is a conference on sharing talks, efforts and researches related to Minix.
It was held once in 2016. MINIXCon2017 was cancelled due to lack of talks submitted.[34][35]
See also
- MINIX file system
- Xinu
- xv6
- Comparison of operating system kernels
- List of computing mascots
- Category:Computing mascots
Notes
References
- ^ a b c "The Minix license". Archived from the original on 2005-11-24. Retrieved 2005-11-24.
- ^ corbet (2005-10-24). "Minix 3 hits the net". Lwn.net. Retrieved 2014-05-01.
- ^ "minix3.org". minix3.org. Retrieved 2017-04-16.
- ^ "Getting Started with Minix on Bochs on Mac OS". Woodhull.com. Retrieved 2014-05-01.
- ^ "OSNews.com". OSNews.com. Retrieved 2014-05-01.
- ^ "Minix under VMWare Installation How-To". Patrick.wagstrom.net. Archived from the original on 2013-11-12. Retrieved 2014-05-01.
- ^ "Minix on Virtual PC: first look". Woodhull.com. Retrieved 2014-05-01.
- ^ "Minix 3 on Virtual box". inopinion.org. 6 August 2014.
- ^ Alting, Ingmar. "A port of the MINIX OS to the PowerPC platform" (PDF).
- ^ "Minix3". Minix3. Retrieved 2014-05-01.
- ^ "git.minix3.org Git - minix.git/summary". git.minix3.org. Retrieved 2022-05-03.
- ^ "Index of /Iso/Snapshot/".
- ^ "minix3 - Google Groups". groups.google.com. Retrieved 2022-05-03.
- ^ "Intel ME: The Way of Static Analysis". blog.ptsecurity.com. Archived from the original on 2017-07-01. Retrieved 2017-08-28.
- ^ Corna, Nicola (2017-08-28). "me_cleaner: Tool for partial deblobbing of Intel ME/TXE firmware images". GitHub. Retrieved 2017-08-28.
- ^ Tanenbaum, Andrew S. "An Open Letter to Intel". Archived from the original on 2022-06-17. Retrieved 2022-09-06.
- ^ Tanenbaum, Andy (2006-09-25). "Introduction to MINIX 3". OSnew. OSnews. Retrieved 2008-07-04.
From Rebirth section: "Various studies have shown that software broadly contains something like 6-16 bugs per 1000 lines of code and that device drivers have 3-7 times as many bugs as the rest of the operating system. When combined with the fact that 70% of a typical operating system consists of device drivers, it is clear that device drivers are a big source of trouble. For Windows XP, 85% of the crashes are due to bugs in device drivers. Obviously, to make OSes reliable, something has to be done to deal with buggy device drivers. Building a reliable system despite the inevitable bugs in device drivers was the original driving force behind Minix 3."
- ^ "CSAIL Event Calendar". Csail.mit.edu. Archived from the original on 2012-02-04. Retrieved 2014-05-01.
- ^ a b "Tanenbaum-Torvalds debate, Part II". Cs.vu.nl. 2006-05-12. Retrieved 2014-05-01.
- ^ "Reliability". www.MINIX3.org. Archived from the original on July 1, 2006.
- ^ "MinixReleases – Minix Wiki". Wiki.minix3.org. Retrieved 2014-05-01.
- ^ "Minix versions and their use in teaching". Archived from the original on 2006-07-11. Retrieved 2021-06-16.
- ^ a b "LICENSE (3.1.0)". GitHub. Retrieved 2021-06-16.
- ^ a b "LICENSE (3.1.1)". Retrieved 2021-06-16.
- ^ a b "LICENSE (3.1.2)". GitHub. Retrieved 2021-06-16.
- ^ Swift, Björn Patrick. "Individual Programming Assignment User Mode Scheduling in Minix 3" (PDF). Minix3.org.
- ^ MINIX Release 3.3.0
- ^ "Minix1: Copying and Use Policies". 2007-02-13. Archived from the original on 2020-06-14.
- ^ "The MINIX 3 Operating System". minix3.org. Archived from the original on 2012-01-13.
- ^ "FAQ – Minix Wiki". Minix3.org. 2013-11-09. Retrieved 2014-05-01.
- ^ "Improvements since V2". www.minix3.org. Archived from the original on April 17, 2006.
- ^ "MINIX Releases". wiki.minix3.org. Archived from the original on 21 June 2012. Retrieved 29 February 2012.
- ^ "mascot [Wiki]". wiki.minix3.org. Retrieved 2017-07-20.
- ^ "Minix3". Archived from the original on 10 November 2017. Retrieved 5 July 2006.
{{cite web}}
: CS1 maint: bot: original URL status unknown (link) - ^ "Minix3". www.minix3.org. Retrieved 2017-11-11.
Further reading
- ISBN 0-13-142938-8.
- Building a dependable operating system: fault tolerance in MINIX 3 by Jorrit N. Herder (PDF)
- Reorganizing Unix for Reliability by Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum (PDF)
- Modular system programming in MINIX 3 by Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S Tanenbaum (PDF)
- J. N. Herder et al., Modular System Programming in MINIX 3, ;Login, April 2006 (PDF)
- Pablo A Pessolani. MINIX4RT: A Real-Time Operating System Based on MINIX Archived 2023-06-07 at the Wayback Machine
- Building Performance Measurement Tools for the MINIX 3 Operating System, by Rogier Meurs (PDF)
- Design and implementation of the MINIX virtual file system (PDF)
- Reference manual for MINIX 3 Kernel API (PDF)
- Towards a true microkernel operating system (PDF)
- Construction of a Highly Dependable Operating System (PDF)
- Minix 3 and the microkernel experience: Smart Kernel by Rüdiger Weis (PDF)
- Safe and Automatic Live Update by Cristiano Giuffrida (PDF)