Minix 3 Test a microkernel OS.....
Try out the kernel that inspired Linux as we explain how to get it running in VirtualBox.
Minix 3 is a microkernel-based Unix clone, targeted towards robustness, reliability, and a small memory footprint. In a microkernel, drivers and servers are isolated, running in User Mode, and restricted in the effects they can have on the rest of the system (more on this later). The price for this is a small performance overhead, and some design challenges, but performance is not as important here as security and stability for most users.
Microkernels have a long history. In the ‘80s, academics were convinced they were the only way forward for OS development, and Minix author Andrew Tanenbaum never considered designing Minix in any other way. It also meant Richard Stallman turned to a microkernel as the basis of the Hurd, the kernel of the GNU OS. The imminent arrival of GNU – and BSD Unix – motivated Tanenbaun to keep Minix as an academic OS, but that fitted well with the aims of having something small enough to teach from, and cover in his famous book, Operating Systems: Design and Implementation.
Legal problems, and then technical challenges, held up the development of the Hurd, but Minix’s tight focus enabled Tanenbaum to produce Minix 1 more or less single-handed, and three decades of putting the few thousands of lines of kernel code under close scrutiny while his doctoral students at Vrije Universiteit, Amsterdam worked on every area, have built a solid foundation for Minix 3.
Despite historical spats with Linux (see Ancienthistory, p75) and the education-targeted early releases, Minix has become an appealing OS for many users, particularly as it’s gradually integrated the NetBSD userland. This has been achieved largely because of millions in EU funding focused on ‘secure and reliable’ OS development, and many generous contributions from the Google Summer of Code.
The Minix team presented the latest version at FOSDEM this year and the ‘MINi UnIX’ has grown in scope, but not in bloat. ARM support, for instance, has made it into the master code branch, and the team say that version 3 has "more complete source compatibility with NetBSD in terms of utilities, calls, types (lots of 64-bit), toolchain, codebase and packages", with "all Minix-specific code in a top-level minix/ subdir".
Minix 3.3.0 isn’t really production-ready, but it could make a stable base for a number of projects, so we’d encourage you to try it, whether on a BeagleBoard or a virtual machine, and keep an eye on developments.
Unfortunately, for those wanting to tinker outside of ARM boards on an old PC, in a desktop fashion, there's a major stumbling block: the X Window System, which was working in the previous release (based on a monolithic XFree86 server), has spectacularly broken. At time of writing, the current release of Xorg was being ported, but still wasn't ready, so it's command-line-only for now. You can, however, download previous releases if you really want to try the desktop. Not all NetBSD packages will run, but compatibility is improving and building from source may enable you to get favourite packages onto your system that aren't in the repos.
Inside the (virtual) box
Minix 3 will install on your x86 PC, but hardware compatibility is limited. Any i586 processor or later should be fine, although problems have been reported on Pentium 4, and the system can work with as little as 32MB of RAM. Peripherals are another matter, however: the list of compatible network cards is short, but includes those emulated by Bochs, Qemu, VirtualBox, VirtualPC and VMware, as well as the BeagleBone's LAN8701A. The remainder of the list is mostly old classics, which will seem familiar if you happen to have experimented with alternative OSes from a decade or more ago: 3Com 509, NE2000, Realtek RTL8139. At least the Intel PRO option is one you're more likely to have on hardware that hasn't been consigned to the attic.
It's probably better to grab a recent Qemu or VirtualBox from your distro's repository; we did most of our installs on
the latter. Click the big New button at the top left of the VirtualBox window, and name your VM. We used MINIX3. Choose Other in both dropdown menus for OS type and version; on the next screen give it as much RAM as you can spare. We'd suggest that 256MB is adequate for Minix 3, but naturally more is better while you're exploring a new environment and pushing to see what it can do. We kept the default 2GB disk size on one VM install, and expanded to 8GB for another. Be inclined towards the latter if you're going to install everything Minix 3 has to offer, but bear in mind 3.3.0's lack of some software from previous releases.
Click Create and you'll see a MINIX3 VM listed in the left pane. Before starting, go to Settings, and tick the Hardware clock in UTC time checkbox, and check that Storage points to your downloaded ISO file. You can now start up the VM from the GUI. On a Core 2 Duo machine, without VT-x/AMD-V/ nested paging, we had to start VirtualBox with:
VBoxSDL --startvm MINIX3 --norawr0 --norawr3
Now follow the instructions in the walkthrough (see p77). Once the installation is complete, use poweroff instead of shutdown to halt the machine. Go back to Settings > Storage in VirtualBox, get rid of the ISO, and point at the newly created virtual disk image instead. Now boot with VirtualBox's Start button (or use the workaround on PCs without VT-x and AMD-V virtualisation extensions).
Running on a BeagleBoard
With 3.3.0, the ARM port of Minix is finally integrated in the master code branch, along with the official x86 port. Targeted at the BeagleBoard, with its Cortex-A8-based system on a chip (SoC), it runs with varying degrees of success on the BeagleBoard-xM (and its Qemu-based emulator), the BeagleBone, and the BeagleBone Black. Pre-built 3.3.0 images are available, but you'll miss out on the latest developments. To build a disk image for your BeagleBoard, make a directory at ~/minix and cd to it – or to wherever you prefer to do the cross-compile – then get the source code:
$ git clone git://git.minix3.org/minix minixsrc
Now cd to minixsrc/ and make a .settings file for BeagleBoard-xM use: # beagleboard-xm U_BOOT_BIN_DIR=build/omap3_beagle/ CONSOLE=tty02
And for the BeagleBone: #beaglebone (and black) U_BOOT_BIN_DIR=build/am335x_evm/ CONSOLE=tty00
Provided you have g++, the GNU C++ compiler, installed, the build tools in Minix will provide you with everything almost else. On Ubuntu you'll also need to:
apt-get install zlibc zlib1g zlib1g-dev
The build tools are based on NetBSD's build.sh. Call the ARM-specific version with:
./releasetools/arm_sdimage.sh
and you should find a minix_arm_sd.img waiting for you to copy across to your SD card, for booting your BeagleBoard or BeagleBone: sudo dd if=minix_arm_sd.img of=/dev/mmcblk0 bs=1M oflag=direct
Put the card in your BeagleBoard, boot up and you can log in as root. Ethernet isn't working on the BeagleBone, but on the BeagleBoards run netconf and select the LAN8710A. USB support on the BeagleBone is tagged as experimental, and there are known issues with hot-plugging on USB hubs in 3.3.0. Audio and the analogue-to-digital aren't yet working either, but GPIO is.
This is a promising first release of the port, and if you've got a BeagleBoard, it's a good sandbox for trying out Minix, particularly as this port will receive a lot of developer time, so you'll see improvements if you keep checking out the code. You can also try the ARM port under emulation with Linaro Qemu, the custom version of Qemu for the BeagleBoard-xM. You can find instructions at: http://bit.ly/LinaroQemu.
Reliability through architecture
Although at an early stage, the ARM port makes sense for an OS that sells itself on reliability and low resource use. The embedded ARM space covers thousands of different devices
where the job of the operating system is, essentially, not to fall over. In consumer devices the mean-time-to-failure should be longer than the life of the device, and Andrew Tanenbaum's stated aim of being finished when "computers don't need a reset button" seems even more applicable here.
Minix’s reliability comes from modularity and fighting bloat. There are 6,000 lines of code in the kernel (see A minimalist codebase, foot of page). Outside of those 6 KLoC (which manage little more than interrupts, scheduling, and message passing) Minix runs everything else in the OS (all the drivers, from the console to the disk drive) in User Mode protecting against bugs and malicious attacks alike. To access memory, drivers and servers have to ask the kernel. No process is permitted to access anything beyond what it needs: the audio driver cannot access the disk drive, for example. The principle of least authority only allows kernel calls relevant for that class of driver, and allocates time slices to prevent infinite loops bringing down the system.
On top of that driver layer sits virtual memory management, the process manager, file systems and the remainder that traditional Unix regards as part of the kernel. These run in User Mode, with the MMU turned on.
User programs sit above this, but all three layers in User Mode are just – as the kernel is concerned – user processes. A crash in the code would bring down the system under Linux, but Minix 3 would merely need to restart the process. The data store server saves the state from crashed drivers, which is retrieved by the new one starting as a replacement. Monitoring all of the servers, and restarting them after a crash, if appropriate, is the reincarnation server.
This is safe to do as most failures are caused by random timing errors and races. Tanenbaum's team have tested this, injecting millions of faults to overwrite 100 machine instructions in the running Ethernet driver binary. They injected 800,000 faults into each of the three different Ethernet drivers, causing 18,000 driver crashes – every time, the reincarnation server automatically replaced the driver.
Of course, you could start attacking the kernel yourself – a comprehensive test suite is included – but first get your system the way you like it. As noted in the walkthrough (see p77), repositories.conf needs editing to have the correct Minix FTP address. Uncomment the NetBSD repo while you're there. If you've never been on a server where vi is the only editing option, I'd recommend installing bsdgames on your laptop, and playing command-line Robots, until HJKL keystrokes are in muscle memory. Now run:
pkgin update
If there's a problem, particularly via NAT on VirtualBox, our best guess is DNS, so put: nameserver 8.8.8.8 in /etc/resolv.conf. Now you can use pkgin search to find packages, for example:
pkgin install vim to install. If you made a larger hard disk partition, and want to install everything at once, use:
pkgin_all If you want to delve deeper, start with the wiki at http://minix3.org, which has a good tutorial on writing device drivers, for example, and plenty of other developer documentation. The user docs aren't too bad, but occasionally pages lag behind by a release version for a while. Naturally, help on updating the wiki would be appreciated by the project as much as more coders – it's actually at the top of the wish list on the wiki!
A bright future for microkernels?
That concludes this overview of Minix 3 – and of microkernels in general. We might be a long way from a usable Hurd, but microkernels have proved their worth in QnX-powered cars [see DrivenbyLinux, p40, LXF187], Cisco routers and elsewhere. Just as a stable alternative for embedded ARM development, Minix 3 is well worth considering. Given its (nearly integrated) NetBSD userland, Minix makes the most usable microkernel OS for those familiar with GNU/Linux, and we confidently expect good things in the next release.