So I really want to get the latest MINIX 3 source code building in a VirtualBox VM, and it's not simple. First, you have to install the latest development snapshot.
Then you have to somehow figure out what features of VirtualBox to turn off in order to make MINIX stable. So far, I've discovered that AHCI SATA doesn't work, 512MB RAM seems to be safe (not too much or too little to rebuild the system), it only supports 1 CPU, I/O APIC and PAE/NX are enabled, nested VT & nested paging disabled.
For MINIX 3, it looks like you also need to emulate the PIIX3 chipset, rather than the newer ICH9. I tried ICH9 and suddently DHCP wasn't resolving DNS and the Internet wasn't working. I have no idea why that is. I'm using the same old PCnet-FAST III (NAT) either way, emulating the universally-supported Am79C973 Ethernet chip (PDF datasheet):
https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/datasheets/21510.pdf
So now it's building /us/src the slowest I've seen so far but hopefully without weird build failures? We shall soon find out.
So here's a story: at work, I'm one of two software engineers working on a plug-in board to handle NIC switch capabilities. We're using a Marvell SOHO router on a chip that can't talk to any x86 module (everyone always uses ARM or MIPS), and it's good to have a dedicated CPU for networking so here we go.
The nice thing about the Marvell switch is you can set up VLANs and do basic routing and it doesn't involve the CPU. Otherwise, a 1 GHz 32-bit Cortex-A is actually a bottleneck for 1 Gbps.
My colleague found out about that broken optimization from someone who worked on the Linux kernel who pointed him at a GitHub repo that had some patches to the kernel for a particular MIcrochip switch, and when we applied just the part involving the checksum, it magically got faster.
I wanted to make sure I understood why it made sense to reverse the commit that was trying to optimize the throughput but failing, and I did.
Sometimes writing the commit is the hardest part of submitting a patch.
That's not the interesting part. What was really unfortunate with an earlier version of the PCB we were testing with was that the CPU would start panicking with "vm page not found" errors that seemed to be correlated with bad RAM, based on Google searches anyway. The only way to make it panic was under the load of "iperf3", a client/server TCP/IP throughput tool that works quite nicely (so does "nuttcp").
Dropping the max CPU speed to 800 MHz made the panics go away. Hmm.
We had a couple different hypotheses and put them all into effect for what we hoped would be (and appears to be) the final version of the NIC board.
One theory was that the RGMII Ethernet signals @ 125 MHz DDR were interfering with the DDR3L RAM signals. So those lines got routed to be on different layers with a ground layer in between. I think one of the chips got rotated to shorted the paths.
Another theory was that the voltages where too variable. SAMA7 seems to have low voltage tolerance.
As you can imagine, we were all both hopeful and anxious that the revised boards that arrived just before Christmas would work reliably, and long story short, they did. 90 MHz to 1 GHz, stable, no problem.
I'm learning a lot to increase my confidence in hardware design and debugging on the job.
Well, it looks like I appeased the MINIX microkernel god(desse)s and my build is continuing to proceed.
Folding@Home defaults to using 1 less thread than the # of threads your CPU has, which typically gets rounded down to the nearest even number from what I've seen. So it's using 14 CPU threads, plus the GPU, leaving 1+ CPU thread free for a MINIX VM.
There's a thermal budget the active CPU cores have to consider, but I'm not in a hurry, as long as the build builds. 🤞
This "current" version of MINIX hasn't been touched since Nov 14, 2018 (just over 6 years).
I've worked with much older codebases. And it supports ELF shared libraries, which is a huge improvement over having to statically link things.
It comes with X11 and a NetBSD-derived package system. Instead of MINIX's original "Amsterdam Compiler Kit", it's now using Clang 3.6, which is old but seems to fit well in 256 MB of RAM (I've set the VM to 512 MB to be safe, and to cache disk blocks).
The binutils linker actually warned me via a note in the shared library that the RC5 block cipher was patented. It looks like the patent may not expire until this November (2025)?
https://patents.google.com/patent/US5724428
This is RC5, not MD5, so I'm not sure if anyone ever used the former for anything important, and the latter is definitely an insecure cryptographic hash.
A simple encryption and decryption device has been developed. The underlying algorithm is a fast block cipher that may be implemented efficiently in hardware or software. The algorithm makes heavy use of data-dependent rotations. The amount of each rotation depends on the data being encrypted and intermediate encryption results. The variables for the algorithm include word size, rounds, and the length of a secret key.
While I'm waiting for this MINIX 3.4.0-something build to finish building (on to the kernel now!), I'm wondering how feasible it is to port MINIX, assuming it's properly stabilized and bug-tested (there's a thorough set of self-tests run with Kyua) to port to 32-bit ARM, Motorola 680x0, PowerPC, RISC-V, or some other more or less-popular CPUs.
64-bit x86 and SMP are two directions you can go as far as future improvements. Paravirtualization support. MINIX does seem to have some "vbox" modules.
Behold the power of MINIX 3.4.0 with the classic twm window manager. MINIX has two test suites, the first for POSIX compliance, and the second are the KYUA tests based on NetBSD:
https://wiki.minix3.org/doku.php?id=usersguide:postinstallation
So here are a couple of #MINIX quality-of-life questions:
1) SMP: how difficult is it to add reliable SMP to the microkernel (and do the service daemons just magically work or if not, how much work is that?)
2) speed: are there any areas that could be sped up by a useful amount, like thread-local variables? Is it easier to port Linux perf or Sun dtrace?
3) what work needs to be done to make it reliable on newer emulated PCs in VirtualBox VMs and presumably therefore in newer PCs (AHCI etc.)?
More #MINIX questions:
4) speed: message passing. Does MINIX use appropriate-sized messages? Should it use async message passing or is the binary signal-type notification sufficient? Any "inner loop" optimizations for x86, other platforms, or generically?
5) what has changed between the MINIX 3.1.0 printed in the 2006 3rd edition of Operating Systems: Design and Implementation (which I own) and the current branch in the MINIX 3 git repo? Are those changes improvements on stability?
@jhamby I had a look at Minix over Christmas and one of the ideas was to see how much work was involved to port it to RISC-V. IIRC the whole build system is derived from (and significantly modified) an old NetBSD build.sh infrastructure which I was unable to get to work for me.
I think a reasonable approach would be to integrate the Minix build process with current NetBSD, this would also automatically provide cross-compilers. That would involve a lot of work, of course...
@jhamby Then one might ask why it's not easier to use NetBSD as a simpler alternative to Linux – its kernel is still monolithic, of course, but you get a much better supported and portable system and the userland components are the same by now.
Reviving Minix would still be worth it, not only for historical reasons. I wonder how many OS courses still use Andy's books compared to more recently published, but architecturally older, approaches like xv6 (which doesn't have a classical textbook).
@me_ Those are excellent and practical points.
I have a few methods to my madness. First, I think FreeBSD, NetBSD, OpenBSD, etc. are just too big to wrap one's head around in terms of booting and operating. I'm testing the limits of what a "normal" person can comprehend as an OS, relative to, say, 8-bit BASIC and ROM routines, or Amiga/Mac/Win3.1, RISC OS, today's Windows and macOS, etc..
I have a thick paperback, Linux Core Kernel Commentary 2nd Ed. from 2001, and it's almost all source code.
I just did some quick math and both the 1st and 3rd edition of the MINIX OS book by Andrew Tanenbaum are about 60% commentary, 40% source code listings. The 3rd ed. is about 46% more pages.
Conversely, the Linux commentary book from 2001 with commentary by Scott Andrew Maxwell is a mere 25.5% commentary and 74.5% source listings.
We have cheap, practically free storage. Source listings in book form are a bit silly, esp. for code analysis (which you can't do, lol).
There's an excellent textbook on 4.4BSD that got turned into a book on FreeBSD, and I have one copy of each version (there's a 2nd FreeBSD version).
I'm not going to pay $60 for a Kindle textbook if the hardcover is $63 new. In the case of this type of book, having the physical book may outweigh searchability? Or not?
jhamby
Michael Engel
morb
lopta