Slashdot Mirror
New Release of MINIX 3 For x86 and ARM Is NetBSD Compatible
An anonymous reader writes MINIX 3 is a small POSIX-compliant operating system aimed at high reliability (embedded) applications. A major new version of MINIX 3 (3.3.0) is now available for download at www.minix3.org. In addition to the x86, the ARM Cortex A8 is now supported, with ports to the BeagleBoard and BeagleBones available. Finally, the entire userland has been redone in 3.3.0 to make it NetBSD compatible, with thousands of NetBSD packages available out of the box. MINIX 3 is based on a tiny (13 KLoC) microkernel with the operating system running as a set of protected user-mode processes. Each device driver is also a separate process. If a driver fails, it is automatically and transparently restarted without rebooting and without applications even noticing, making the system self-healing.
The full announcement, with links to the release notes and notes on installation, can be found at the Minix Google Groups page.
The novel approach is that Tanenbaum invented the fucking thing. The specific current advantage is low-latency IPC--on ARM, Minix IPC doesn't even have a measurable cost (the context switch time required is under 20 microseconds), while on x86 IPC is more than 10 times faster than L4.
Monoliths, e.g. Linux, don't have IPC latency because they don't context switch when making calls between major kernel functional units. Of course, if your network driver crashes, your whole system gets fucked up and dies; whereas Minix tries to take a state snapshot, reconstruct something workable, load it into a fresh run of the network driver, and continue without a hickup. This works extremely well with the disk and FS drivers. Ideally, we want this without paying for it.
Support my political activism on Patreon.
The file system write or read request doesn't return anything, the driver is detected as dead (heartbeat?), it's killed, resurrected, journals are replayed, and the request is resubmitted to the FS driver.
It'll work. The program might notice a small pause, as if the disk was busy or the kernel yielded schedule to an interrupt handler.
Support my political activism on Patreon.
You can reconstruct state. A read request from hard disk will work the same way, repeatedly; a write request to a file system will write to a journal or the same blocks in a file or inode, while a write to a hard drive sector is isometric. Keeping the request buffer, resubmitting the request, and so on lets you reconstruct state. Even a network driver theoretically could read state from the network: it could request DMA from the NIC to a buffered memory area with a control structure of known layout, and the resurrection server could provide the control structure and buffered memory areas back to the driver if it needs to restart.
The remainder of the driver state can be discarded. Bringing in new network frames, new writes to file systems, or the like shouldn't depend on the driver's internal state. Repeated crashing--for example, reloading the network driver as above and having the control structure point to a buffer of unmapped memory--could signal the OS to simply drop state and start fresh. Recovery is possible in many cases: TCP/IP, as a separate driver, would simply experience a dropped frame (lost packet), handling a state-reset network driver the same way as any other faulty media; a failed hard drive write would signal the FS driver to resubmit its write; and a failed file system operation could go so far as to reload the driver and run a journal replay or file system check (non-journaled file systems could use an in-memory journal to facilitate file system driver recovery).
Consider state as a collection of significant and insignificant states. My Web browser right now has a lot of stuff in memory, a lot of things rendered on the screen, a state of how far down I've scrolled, and state describing where in memory all these things are--and where this text I'm typing is stored. If we unload the browser and then re-launch, the only state I need restored to post this message is a copy of this message, dumped anywhere in RAM, with a specific pointer somewhere referencing that buffer as the context of this particular textbox on this Web site. The browser's state may be completely different, yet only that piece of information is important; I can recover the rest by coming to this page and hitting "Reply To This".
From that view, it's not hard to recover discrete processes in an OS. File system separate from disk driver means the FS can handle a disk driver crash and reload; user prorgrams won't notice a file system driver crash if the system just waits for the FS driver to reload and replay a journal or such to return state to sanity. The task entry for the user program tracks all the file handles. All of these things are separate, can communicate between mediators, or can mediate their own communications.
Support my political activism on Patreon.
As an embedded-systems guy, I'd _love_ to have a Unix-like where I could schedule events that were guaranteed-by-design to fire within some deadline of when they were scheduled. Then I could host my once-per-kHz hardware service routines on the same processor that was also running my device's web-server.
Minix's microkernel architecture seems like an ideal fit for that kind of use case. If there are any Minix devs reading this thread, how easy would it be for me to make a system like that using Minix?
---- I'll take you in a Hunt deathmatch any day.
Magic bullet? There never are any magic bullet for complex systems.
A microkernel is the realization of best practices for security systems and - dare I say it - follows the original Unix philosophy.
Do one thing (IPC) and do it well (ensure security guarantees are kept). Keeping the critical code small makes it easier to verify code in both the practical and mathematical sense.