- MINIX 3
Minix 3 running X11 with TWM as Window Manager.
Company / developer Andrew S. Tanenbaum OS family Unix-like Working state Current Source model Free and open source software Latest stable release +/−] Latest unstable release +/−] Supported platforms i386 architecture Kernel type Microkernel Default user interface ash License BSD License Official website www.minix3.org
The main goal of the project is for the system to be fault-tolerant by detecting and repairing its own faults on the fly, without user intervention. The main uses of the operating system are envisaged to be embedded systems as well as the education sector, such as universities or the XO-1 laptop.
MINIX 3 currently supports IA-32 architecture PC compatible systems. It is also possible to run MINIX under emulators or virtual machines, such as Bochs, VMware Workstation, Microsoft Virtual PC, and QEMU. Ports to the PowerPC and ARMs (Intel XScale) are in development.
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) can bring down the whole system, MINIX 3 aims to create an operating system that is a "reliable, self-healing, multiserver UNIX clone".
In order 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 known as the reincarnation server. If a driver fails to respond to pings from the reincarnation 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, something that is much less likely to occur in MINIX 3.
MINIX 3 versions  Version Release Date Description 3.1.0 2005-10-24
- The first release of MINIX 3 (Book Release).
- New Packman package manager.
- Fixed an installation issue with auto-partitioning disks.
- Added new Virtual File System
- Bug fixes.
3.1.4 2009-06-09 3.1.5 2009-11-05
- Improvements performance
- Shared memory
- setitimer function
- ISO 9660 file system
- Open Sound System
- Trap NULL accesses now, for user convenience
- Improved signal handling
- Better support for debuggers (ptrace improvements, etc.)
- Network card autodetection (for supported PCI cards), improved network configuration
- New Network drivers: Atheros L2, Intel E1000, Realtek 8169, DEC Tulip
- PipeFS - removed pipe handling from filesystem drivers
- HGFS - support for mounting VMware shared folders as file system
- VFS: supplemental group support and sticky bit support
- Floating-point unit support
- System Event Framework (SEF)
- Experimental APIC support
3.1.7 2010-06-16 3.1.8 2010-10-04 3.2.0 2010-10-04
- Porting GNU Debugger to MINIX 3 and implementing core dumping support
- FUSE Support with experimental NTFS-3G file system
- Replace the old and obsolete MINIX userland with NetBSD Userland
- Replace the default compiler ACK with GCC and Clang
- Switch to ELF and NetBSD libc libraries
- Pkgsrc Upstreaming and Application Porting
Current stable release
Current development release
MINIX 3 was publicly announced on 24 October 2005 by Andrew Tanenbaum during his keynote speech on top of the 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."
Reliability in MINIX 3
One of the main goals of MINIX 3 is reliability. Below, some of the more important principles that enhance MINIX 3's 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, which can make problems easier to find in the code.
Cage the bugs
In monolithic operating systems, device drivers reside in the kernel. This means that when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. A single bad line of code in a driver can bring down the system. In MINIX 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform arbitrary I/O, or write to absolute memory. They have to make kernel calls for these services and the kernel checks each call for authority.
Limit drivers' memory access
In monolithic operating systems, a driver can write to any word of memory and thus accidentally trash 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. For some drivers (e.g., disk and network) recovery is transparent to user processes. For others (e.g., audio and printer), the user may notice. In monolithic systems, dereferencing a bad pointer in a (kernel) 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 system, a looping driver could hang the system.
Limit damage from buffer overruns
MINIX 3 uses fixed-length messages for internal communication, which eliminates certain buffer overruns and buffer management problems. Also, many exploits work by overrunning a buffer to trick the program into returning from a function call using an overwritten stacked return address pointing into the overrun buffer. In MINIX 3, this attack does not work because instruction and data space are split and only code in (read-only) instruction space can be executed.
Restrict access to kernel functions
Device drivers obtain kernel services (such as copying data to users' address spaces) by making kernel calls. The MINIX 3 kernel has a bit map for each driver specifying which calls it is authorized to make. In monolithic systems every driver can call every kernel function, authorized or not.
Restrict access to I/O ports
The kernel also maintains a table telling which I/O ports each driver may access. As a result, a driver can only touch its own I/O ports. In monolithic systems, a buggy driver can access I/O ports belonging to another device.
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. The detection and replacement of non-functioning drivers is automatic, without any user action required. 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 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.
As can be seen, at the bottom level is the microkernel, which is about 4,000 lines of code (mostly in C, plus a small amount of assembly language). It handles interrupts, scheduling, and message passing. In addition it supports an API of about 30 kernel calls that authorized servers and drivers can make. User programs cannot make these calls. Instead, they can issue POSIX system calls which send messages to the servers. The kernel calls perform functions such as setting interrupts and copying data between address spaces.
At the next level up, we find the device drivers, each one running as a separate user-mode process. Each one controls some I/O device, such as a disk or printer. The drivers do not have access to the I/O port space and cannot issue I/O instructions directly. Instead, they must make kernel calls giving a list of I/O ports to write to and the values to be written. While there is a small amount of overhead in doing this (typically 500 nsec), this scheme makes it possible for the kernel to check authorization, so that, for example, the audio driver cannot write on the disk.
At the next level we find 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 actually 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 file 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 found in Linux and Windows systems to about 20,000 lines greatly enhances system reliability.
Differences between MINIX 3 and prior versions
MINIX 1, 1.5, and 2 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 C and some x86 assembly language. Source code of the kernel, memory manager, and file system of MINIX 1.0 are printed in the book. Tanenbaum originally developed MINIX for compatibility with the IBM PC and IBM PC/AT microcomputers available at the time.
MINIX 1.5, released in 1991, included support for MicroChannel IBM PS/2 systems and was also ported to the Motorola 68000 and SPARC architectures, supporting the Atari ST, Commodore Amiga, Apple Macintosh and Sun Microsystems SPARCstation computer platforms. A version of MINIX running as a user process under SunOS was also available.
MINIX 2.0, released in 1997, was only available for the x86 and Solaris-hosted SPARC architectures. Minix-vmd was created by two Vrije Universiteit researchers, and added virtual memory and support for the X Window System.
“ 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. ”
There have also been many improvements in the structure of the kernel since MINIX 2 was released, making the operating system more reliable.
MINIX version 3.1.5 was released 5 Nov 2009. It contains X11, Emacs, vi, cc, GCC, Perl, Python, Almquist shell, Bash, Z shell, FTP client, SSH client, Telnet client, Pine, and over 400 other common UNIX utility programs. With the addition of X11, this version marks the transition away from a text-only system. Another feature of this version, which will be improved in future ones, is the ability of the system to withstand device driver crashes, and in many cases having them automatically replaced without affecting running processes. In this way, MINIX is self-healing and can be used in applications demanding high reliability.
- Tanenbaum, Andrew S; Albert S. Woodhull (14 January 2006). Operating Systems: Design and Implementation (3rd ed.). Prentice Hall. ISBN 0131429388. http://www.pearsonhighered.com/educator/academic/product/0,,0131429388,00%2Ben-USS_01DBC.html.
- Building a dependable operating system: fault tolerance in MINIX 3 by Jorrit N. Herder
- Reorganizing UNIX for Reliability by Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S. Tanenbaum.
- Modular system programming in MINIX 3 by Jorrit N. Herder, Herbert Bos, Ben Gras, Philip Homburg, and Andrew S Tanenbaum
- J.N. Herder et al., Modular System Programming in MINIX 3, ;Login, April 2006 
- Pablo A Pessolani. MINIX4RT: A Real-Time Operating System Based on MINIX 
- Building Performance Measurement Tools for the MINIX 3 Operating System, by Rogier Meurs 
- Design and implementation of the MINIX Virtual File system 
- Reference manual for MINIX 3 Kernel API 
- Towards a true microkernel operating system 
- Construction of a Highly Dependable Operating System 
- Minix 3 and the microkernel experience: Smart Kernel by Rüdiger Weis
- ^ Arun Thomas (04 Oct 2010). "Minix 3.1.8 Release". http://groups.google.com/group/minix3/msg/32df210191b33f85?noredirect.
- ^ "Source repository". http://gforge.cs.vu.nl/gf/project/minix/scmsvn/?action=browse&path=tags.
- ^ "LWN.net." LWN: MINIX 3 hits the net. 28 Oct 2005. Eklektix, Inc.. 4 Jul 2006 .
- ^ Woodhull, Al. Getting Started with Minix on Bochs on Mac OS. 20 Feb 2003. 8 Jul 2006 .
- ^ Senn, Will. "OSNews.com." Virtually Minix: A Tutorial & Intro to Minix on XP via Bochs - OSNews.com. 08 Jul 2006. OSNews.com. 8 Jul 2006 .
- ^ Wagstrom, Patrick. Minix under VMWare Installation How-To. 8 Jul 2006 .
- ^ Woodhull, Al. Minix on Virtual PC: first look. 02 Jun 2005. 8 Jul 2006
- ^ Alting, Ingmar A. MinixPPC: A port of MINIX 3 to the PowerPC platform, 15 Sep 2006. 
- ^ MINIX 3 Operating System official website
- ^ Download
- ^ Tanenbaum, Andy (2006-09-25). "Introduction to MINIX 3". OSnew. OSnews. http://osnews.com/story.php/15960/Introduction-to-MINIX-3. 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.""
- ^ Tanenbaum, Andrew. CSAIL Event Calendar. 25 Aug 2006 .
- ^ a b Tanenbaum, Andrew. "Tanenbaum-Torvalds debate, Part II:." 12 May 2006. Vrije Universiteit. 15 Jun 2006 .
- ^ Tanenbaum, Andrew S.. "Reliability." The MINIX 3 Operating System. Vrije Universiteit.. 22 Jun 2006 
- ^ MINIX Releases
- ^ Woodhull, Albert S.. "MINIX 3: A small, reliable free operating system:" MINIX 3 FAQ. 24 Oct 2005. Vrije Universiteit. 15 Jun 2006 .
- ^ Tanenbaum, Andrew. "The MINIX 3 Operating System." Improvements since V2. 05 Jul 2006 .
- Minix3 official homepage:
- MINIX 3: a Modular, Self-Healing POSIX-compatible Operating System on YouTube
- http://www.minix3.ru - official russian site
- comp.os.minix - official forum(since 1987)
- A very good description of Minix 3 by Andy Tanenbaum
- MINIX: what is it, and why is it still relevant? An interview with Andy Tanenbaum
- Minix Network Service Documentation
- Can We Make Operating Systems Reliable and Secure?
- Minix Tips for running the Operating System Version
- Minix3 installation on YouTube
Unix and Unix-like operating systems
Wikimedia Foundation. 2010.
Look at other dictionaries:
MINIX — The MINIX 3.1.8 boot screen Company / developer Andrew S. Tanenbaum … Wikipedia
Minix — 3.1.3a Разработчик Эндрю Таненбаум … Википедия
Minix — Parte de la familia Unix MINIX 3.1.2a Desarrollador … Wikipedia Español
MINIX FS — ó MINIX file system Desarrollador(a) Comunidad Open Source Nombre completo MINIX file system Introducido (MINIX 3.1.2) Identificador de la partición Estructuras Contenido del directorio … Wikipedia Español
MINIX — 3.1.2a Minix est un système d exploitation, clone d UNIX, fondé sur un micro noyau créé par un professeur nommé Andrew S. Tanenbaum à des fins pédagogiques, volontairement réduit afin qu il puisse être compris entièrement par ses étudiants en un… … Wikipédia en Français
Minix — 3.1.2a Minix est un système d exploitation, clone d UNIX, fondé sur un micro noyau créé par le professeur Andrew S. Tanenbaum à des fins pédagogiques, volontairement réduit afin qu il puisse être compris entièrement par ses étudiants en un… … Wikipédia en Français
MINIX fs — Introduction 1987 (MINIX 1.0) Identificateur de partition 0x81 Limitations Taille maximale du nom de fichiers 14 Taille maximale de volume 64 Mio … Wikipédia en Français
MINIX Fs — est le système de fichiers utilisé par l OS Minix et le premier à avoir fonctionné sous Linux. Il a de nombreuses limitations (partition de 64 Mo et noms de fichiers de 14 caractères au maximum, un seul horodatage, etc). Néanmoins il reste très… … Wikipédia en Français
Minix fs — est le système de fichiers utilisé par l OS Minix et le premier à avoir fonctionné sous Linux. Il a de nombreuses limitations (partition de 64 Mo et noms de fichiers de 14 caractères au maximum, un seul horodatage, etc). Néanmoins il reste très… … Wikipédia en Français
Minix — hat im EDV Bereich folgende Bedeutungen: das Betriebssystem: siehe Minix (Betriebssystem) das Dateisystem: siehe Minix (Dateisystem) Diese Seite ist eine Begriffsklärung zur Unterscheidung mehrerer mit demselben Wort bezeichne … Deutsch Wikipedia