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 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.
No idea. I've seen the performance tests where they repeatedly send kill signals to the disk driver to crash it over and over, and measure its impact on performance--large when you have this in a tight loop, yet the system trudges along, and stops being so god damn slow when you stop killing the disk service 1000 times per second.
I can conjecture a lot about how it is and isn't possible--obviously you can't just restart a snapshot from a few ns ago, or tell it to try again, or rerun the service and dump the same exact data back over it; but you can resubmit requests and messages in any number of ways. If you're careful to use a request-acknowledge-free workflow (send a request, wait for an acknowledgement that it's completed, then free the memory for the request when it's acknowledged or when the requested information is returned), you can always replay a request if the server dies. You can even use a mediator to resubmit uncompleted requests or stored state (received frames, journaled file system actions, etc.) to a service if it gets restarted, hiding that process from other services.
Minix documentation and demonstration show that they restart the service and it completes all requests--state is snapshotted and restored. How that state is snapshotted--internal to service, mediated by a message passer, or resubmitted by client services--I don't actually know. I just know it does it and it's technically possible in any number of ways.
Support my political activism on Patreon.
Last time I looked at this, L4 was some 1-2mS context switch on x86, back in the 1GHz chip era; Minix was 100uS; and it was some 20uS on ARM. ARM is a good architecture--even L4 was ridiculously fast on ARM. Mach was slow as balls all the time.
Support my political activism on Patreon.
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.
VxWorks?
VxWorks is a great product. It's also waaaayyy outside of the price range of a hobbyist developer. Getting up and running with the VxWorks suite of tools can easily cost 20k (USD), and the recurring license fees are pretty significant as well. I would also bet that auditing the VxWorks source code (or trying to get custom patches in) would cost significantly more.
---- I'll take you in a Hunt deathmatch any day.
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.
Your requirements mean you want a Real Time operating system - one that guarantees execution of a interrupt or other thing within a fixed deadline.
If your deadline is a do-or-die thing, you have a hard-real-time requirement (i.e., it's a failure if you're late, period). if your deadline is more of a "well, please try not to, but under exceptional cases you can be a bit late" then it's firm real-time, and if it's "well, try not to be late, but it's OK if you are" then it's a soft real-time requirement.
(Note: general purpose OSes often do run tasks that do have hard or soft realtime requirements. E.g., responding to a keyboard is generally a soft-to-firm realtime requirement - the user types something and generally expects a prompt response or the system will seem "slow". A hard realtime requirement would be playing back audio where failure to prepare a new block of audio results in a pop/skip/burp of the audio. Or back in the old days, burning a CD. If you didn't keep the buffers full, you'd be out a disc).
Of course, a RTOS guarantees the deadline regardless of load.
And there are a few that are POSIX compliant - QNX for one. There's also RTLinux which runs Linux as a general task within a realtime framework. I'm not sure if RedHat still maintains it, but eCos was an RTOS as well.
And yes, RTOSes are capable of that - handling a 1kHz process plus a webserver at general processing - the RTOS knows it needs to service that task at 1kHz and will pre-empt the webserver as required.