> In fact, selfie goes one step further by implementing microkernel functionality as part of the emulator and a hypervisor that can run as part of the emulator, on top of the emulator, and even on top of itself, all with the same code.
> The design of the compiler is inspired by the Oberon compiler of Professor Niklaus Wirth from ETH Zurich. The design of the selfie microkernel is inspired by microkernels of Professor Jochen Liedtke from University of Karlsruhe.
As someone who is vaguely trying to learn more about / get involved in kernel development, the easiest place to start figuring things out is in simpler kernels like this or Minix. (Then followed by OpenBSD. Then later on NetBSD / FreeBSD. Then much, much further, Linux. [Haven't spent time looking into Illumos yet but it's on the list.]) But I haven't actually been able to contribute much more than ports to any of these yet.
In 16-bit mode, it runs beautifully (there's not quite enough RAM for the bigger 32-bit binaries). It's a pretty good Unix, with networking support, cut down versions of all the standard tools, it comes with full source and several toolchains making it almost completely self-hosted, and it'll rebuild its own kernel in 13 minutes.
It is beautiful. If you're interested in operating systems, definitely take a look. (There is a Minix 3, but I find it doesn't have the same minimalist charm.)
They have same name but aren't really related. Minix 3 is a new OS designed to take place of a modern UNIX with higher reliability. They ported a NetBSD userland to get UNIX apps working. Main benefits are reincarnation server and more code being user-mode (i.e. limiting damage).
The one oddity I noticed in my brief testing was that the Minix DHCP client doesn't allow for setting your own hostname, even though NetBSD's does.
It might be worth noting that Liedtke is the architect of the reasonably well-known L4 microkernel.
34 kLOC instead of 7, and no fancy VM/kernel stuff, but it does full C99.
c4 is what you might call a microscopic C compiler; it's surprising how much it does for the code it has.
Sadly, the Opengroup and Linux man pages say that
> Memory access within the mapping but beyond the current end of the underlying objects may result in SIGBUS signals being sent to the process.
I might do a write-up if I do. I did code a problem or two afterward. Reusing principles from high-assurance systems and security helped. Keep design, language, & implementation simple. Straightforward control flow with no looping between layers. Safe language. Straight-forward toolchain. I ended up doing those problems in a subset of FreeBASIC since I was up and running so fast w/ no fighting with IDE's, etc. Solutions came out correct in first implementation due to design principles & refactoring specs on paper. Coding phase simply didn't have much room for added error.
If they only made one more step and combined these two into a single machine word type, they'd get B...
Some of things I saw in the source (such as casting string literals to an int) made me cringe a bit, but remembering it is truly a very small subset of C, I'll give it a pass.
Overall, the code quality seems pretty high and is very easy to read (I quickly read through maybe 20% of it).
I think it'd be easier to follow if it broken up into separate files, but I noticed they didn't implement a preprocessor, so I assume part of the rationale for a single file was to avoid includes, macros and all the other baggage the preprocessor brings with it.
I'll definitely have to come back to this project later when I've more time to look at it.