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.
with today's HW. Haha, wouldn't that be funny if ten years from now Linux and Minix switched places?
Nah...
Does anybody know what exactly is novel in the Minix 3 approach? Microkernels (or small macrokernels) with restartable drivers are well known and already used in the real world.
If a driver fails, it is automatically and transparently restarted without rebooting and without applications even noticing, making the system self-healing.
When things are restarted they lose their state. I don't see how applications will not notice that. For example, if an application has an open file handle, it seems unlikely that the file system could be "restarted" without a write failing.
Making it netbsd compatible is a stroke of genius.
Don't present userspace drivers as a panacea for all kinds of driver troubles: when a driver fails, it can make the hardware it drives hang your machine solid from the hardware's side, or make said hardware DMA all over your RAM with complete disregard any CPU-imposed protection; there's no safe recovery from such a situation, and in this case applications had better be stopped even if they appear to be still running.
Uhhh... I think you switched the cart and the horse, there, fella.
http://en.wikipedia.org/wiki/L...
Uh, no. Minix predates Linux by decades. Check your history, boy.
Please leave your geek card on your way out...
I've got better things to do tonight than die.
Why?
Check your history. Minix predates Linux by 4 years (1987 vs. 1991).
THAT'S DECADES!!!
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.
you forgot to mention its slow too
I don't want to do a sig now
Betcha emacs does.
> Minix needs a bunch of drivers implementing kernel event hooks, inotify, dnotify, etc. Essentially, everything for udevd,
> systemd, and dbus.
No, please let systemd out of Minix. Lets not contaminate another Unix implementation with it.
And when it's all done, it will be more complex than Linux.
From what I've seen, Minix is fast. It's built for speed, avoiding many costs of IPC the same way Linux does.
In Linux, the address space is split. IA-32 4G/4G causes a full TLB and cache flush at syscall entry and return, creating massive slowness. IA-32 normal 3G/1G operation puts 1G at the top for kernel mappings and 3G at the bottom, while x86-64 puts 128TB at the top and 128TB at the bottom. In both cases for split address space, there's no TLB or cache flush when syscalling into the kernel; and returning to user space requires only selective cache and TLB invalidation, removing kernel-private data and leaving userspace data in tact. This greatly improves cache utilization and reduces expensive pagefaults by completely avoiding the kernel/user context switch, replacing it with a simple mode switch.
In Minix, the many kernel contexts make all the same mappings, but lock access to the specific service. It's the same as Linux's split mapping, but with parts of the kernel unable to access other parts; IPC involves a few TLB and cache invalidations in each direction. This strategy lets you run an entire round trip call in under 100nS. It's about as long each way as a CALL and RET, so it's about the overhead of adding a function call along the code path.
Support my political activism on Patreon.
Although Minix does use some of the same tricks Linux does it still has additional overhead of separate servers and message passing. L4 still has a 2% to 4% penalty vs a monolithic kernel. You can optimize it all you want but the piper must be paid and won't go away.
I don't want to do a sig now
systemd is a reason to consider switching from Linux to Minix.
Should be 0.14us as per the title
But it will be complex in small, discrete, independently-verifiable pieces, like a cookie with raisins, M&Ms, and a peanut butter cup arranged on top rather than a chocolate-peanut-butter cookie with raisin puree mixed in.
Support my political activism on Patreon.
It has a 2% to 4% penalty for IPC, specifically. This is like when Theo de Raadt chose to argue with me that position-independent executables were "very expensive" and had "high performance overhead," and I pulled out oprofile and found that 0.2% of the execution time occurred in the main executable--which was 6% slower (when including -fomit-frame-pointer no longer providing a 5% boost), giving a total overhead of 0.012% total system slowdown--a few seconds lost per day.
The difference is I was doing that back then, and not referencing shit I did 10 years ago.
Minix's overhead is small. Minix uses fixed-length buffers, zero-copy strategies, mode switching, and the like to avoid doing any real work for IPC. It's like adding a function call to your code paths--like if you called get_fs_handle() and it called __real_get_fs_handle() without inlining it.
Support my political activism on Patreon.
I've followed Minix development with interest. The internal architecture is different from most OSs out there. Not different for the sake of being different, but different to show different solutions to problems. The way we do things in Linux et al is powerful, but it's not the only way.
I haven't come up with a compelling reason to use it in my work (yet... :-), but I install each new release on a virtual machine
and play with it.
...laura
Will be this the real Hurd?
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Its still going to be slower no matter what you do.
I don't want to do a sig now
Not necessarily.
There is a single, absolutely-optimal way to implement a computer program for a specific task in a specific language on a specific compiler targeting a specific CPU platform for a specific CPU model. In practice, we worry more about code readability, code maintainability, and the general-purpose usefulness of the operating system.
Given what I said--that IPC carries about as much overhead as a function call when calling out to another part of the kernel--we don't even have to consider whether that overhead is so negligible as to be ludicrous to account for or whether it's incredibly large. The only practical impact is the same as using OpenBSD versus NetBSD versus FreeBSD versus DragonFly BSD: different approaches are taken in various kernels to solve the same problem, and they all jump through different numbers of lines of code, different interactions (i.e. DIV takes more cycles than SHR), different call traces (more or fewer function calls passing more or fewer arguments), and so on.
In other words: the overhead is on the level that calling it "slower" is an abuse of terms, the same as claiming that the execl() call shouldn't be a wrapper for execve() because it makes the system slower. The practical impact isn't just small; it's smaller than the practical impact of every other factor in the execution of the code in question, and thus has no real implications for performance as an architectural consideration.
Support my political activism on Patreon.
It's a decade to an order of magnitude.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
How so? As opposed to making it compatible w/ FreeBSD, which is a lot more popular?
I welcome the addition of Beaglebone support, but would like to see support spread to Arduino and Raspberry Pi platforms. Minix won't be a first choice for any laptops, but it sure can be the first choice of these cards, where the small footprint actually helps.