OSDev.org

<shill>
http://www.redox-os.org/
</shill>

I'm not involved with it (I still haven't even learned Rust as of yet), but these guys didn't start all that long ago and yet the project has boomed and shown some serious progress.

As such, I've been really surprised to see, to my knowledge, no mention of it here. But maybe I'm just an ******* who hasn't been paying attention.

Looks pretty neat, actually.

You're right, it hasn't been mentioned here (except for the Wiki) according to the search results. I heard about it earlier. That's a great project!

Browsing their git repository, I started wondering how they call is 'microkernel' even in design. The kernel directory includes stuff like audio, disk, drivers, graphics, network, usb.. Either they organize their codebase funny, or just use that phrase for marketing.

Hellbender, yeah I thought the same thing. I didn't look very closely but I did notice in their docs that they are hoping to reduce the size of the kernel. Perhaps they intend to move it out.

shrug The term 'micro-kernel' has gotten stretched pretty far over the years, going back to the original Mach kernel or earlier. As I've mentioned here before, I've even seen the Windows NT kernel described as one (in one of William Stallings' book), which is total nonsense. Almost all kernels described as micro-kernels are actually hybrid kernels and quite a few are not 'micro' at all.

Keep in mind that 'micro-kernel' isn't quite what most people think it is. While most OS-devvers know that one of the defining qualities of a micro-kernel is that device drivers are separated from the kernel, many are under the impression that this is the only such defining quality, and only a few seem to know the historical origins of this and the original purpose for such designs. Plenty seem to think that it is defined as 'having drivers run in userspace instead of kernel space', which is a notable misunderstanding as it highlights the changes that have occurred in stock hardware since the concept was developed.

In point of fact, the original definition of 'micro-kernel' was a system that did not compile the whole operating system into a single binary, and used message-passing for inter-process communication and synchronization. It did not discuss separating part of the system facilities out into userspace at all.

The reason for this is simple: the primary purpose of the design was to build a multitasking system that could be stable on systems that had no hardware memory management, like the 6809, 68000, and 8086. The whole idea came about as a way of working around the limitations of the then-current microprocessors without resorting to a monotasking system. Like with the contemporaneous development of RISC hardware (which also had its roots partly in the need to get around a barrier, in that case the limits of the IC foundry that UC Berkeley set up for their students in the 1970s), it proved to have several technical advantages unrelated to that, but those didn't become evident until later.

While they inspired a lot of innovation, and led to pretty much the elimination of monolithic kernels in their original form (essentially all non-toy systems called monolithic today are also hybrid, including Linux and Windows), 'pure' micro-kernels were a solution to something that is no longer a problem on 99% of stock hardware.

Purely devil's advocate:



So kind of like NT, then?

Yeah, hence the claim. I'm not saying that the claim doesn't have any merit, just that it is 'technically correct - the best kind of correct', rather than a meaningful description. Also, the NT kernel has several kinds of IPC primitives, not just message-passing - I should have said 'used message-passing as the sole primitive for inter-process communication and synchronization', since the primary idea was that less abstract synchronization primitives such as semaphores were more prone to bugs, and more likely to get misused or sabotaged.

Anyway, the reason for this whole pedantic aside was not to say that the term was being misused, but that the idea has evolved a lot since it arose. In the real world, 'pure' designs are rarely practical ones - and yes, I am aware that there is a bit of hypocrisy in me saying that, but I am no longer aiming at writing a world-beating OS; purity is just fine for a research project, and in fact is in some ways a necessity to reduce implementation variables.

I don't accept the word 'hybrid' as an accurate, technical description of anything unless the description tells me what 2 things it is a hybrid of. Windows NT and Linux may be hybrid kernels but they are not hybrids of a microkernel and a monolithic kernel. They are simply different variants of the monolithic kernel. As far as I can tell neither has any of the important traits of a microkernel.

Of course, if 'hybrid' is being used as a marketing term then we can ignore its actual meaning as we ignore the literal meaning of most terms used in marketing. I have no problem with that.

Back on topic, Redox does claim to be a microkernel. Unfortunately, I don't read Rust so can neither confirm nor deny it but reading the docs makes me think that it probably is a microkernel.

Redox OS progressed a lot since 2016, in the beginning things needed to be moved out from the kernel.

Actually the kernel have less than ~9k SLOCs and have WIP x86/ARM64 ports.

The changes since 2016 are gigantic to say here, you can read in our blog section of the website (News page).

We are at GitLab, we have a FAQ, self-hosting is close, our own in-house C library and more than 100 software ported (some recipes contains dirty patches because we don't have complete POSIX support in our C library).

https://redox-os.org

I'm the Community/Documentation Manager of this project.