I was reading OSNews a couple of days back, and came across an introduction to a new experimental kernel called Multiplix. Recognising that Haiku has a pretty decent kernel for the x86, and x86 will remain the main platform for the near future at least, it got me wondering whether there might be benefits in investigating Multiplix for Haiku ARM and Risc-V ports?
I understand that these RISC designs tend to have lots of smaller cores whereas the x86 focusses on fewer, more powerful ones. This might make a different kernel optimal in the future. Might we use Multiplix, either in full or in part, to acheive that?
Multiplix shares Haikuâs MIT licence. The Multiplix kernel is also intresting in that it is mainly written in âDâ, with a bit of âGoâ thrown in for good measure!
Using the same kernel base allows to share more things. So developments made on one side are allowing to progress on all architectures with small or no adaptations.
I guess that with different kernels, methods to access devices and memory would be so different that it wouldnât be worthy to adapt things and you would have to rewrite them.
This said, if there are good ideas, why not get inspiration from them. And man could borrow them since the licence allows it.
Switching kernel is kind of like a heart transplant, and with different languages (and probably build systems) it would be like a heart transplant from another species.
The current status is that Multiplix can boot all cores, enable virtual memory and interrupts, supports multiple user-mode processes with a limited set of system calls, and has a simple Unix-like file system. Current work is focused on expanding the system call interface to support a shell and a basic user-mode environment.
So, this kernel cannot even handle system calls yet. Which means, pretty much no userland, they have a âmonitorâ that is something similar to our kernel debugger.
So, it sounds like a jump 15 years back in time for Haiku. And then it would take us another 15 years to get that kernel back to where our own already is.
If youâre going to attempt porting Haiku userspace to another kernel, Iâd suggest picking one that already worksâŚ
Well, you were warned in the subject that this would be a speculative discussion, not necessarily practical!
I presume the name Multiplix is a riff on Unix, which in the mists of time itself was a pun on a predecessor called Multics. Thus the naming wheel makes a full turn. It implies to me that it is designed to make use of modern multiple core RISC chips. This appeals because it reminds us of the groundbreaking multi-threaded nature of BeOS, in the days when having two cores in your PC was a bit flash.
These are good points. But, playing devilâs advocate, the RISC chips are a different thing which might phase in over a long time, and the app binaries will have to be different (as they are with the 32 bit and 64 bit editions). Haiku can probably plan for and cope with a divergent RISC edition.
Whilst Multiplix might make better use of the the cores on modern RISC chips, speculating about the effect of introducing new languages into the codebase might be more fun!
Lets say I built Haiku running on Multiplix kernel. Would Multiplix act like a trojan horse, where the more modern D and Go languages start spreading into other parts of the core system over time as they are re-written? Would more developers join Haiku to play with these languages at the systems level? Or would the opposite happen and the âbetterâ languages get displaced by âgood enoughâ C++? Or would it all remain static?
You would have few contributors following the announce on OSNews. As time will go by, they will disappear because one or more languages would be âhas beenâ. Anyway nobody would fully understand the code because of the mix. And the rare people staying around will start to ask you about rewriting all using the new thing on the mood.
One of Haiku selling points is a single team working on the whole project in a single language. It is already hard enough to do that with a single programming language. Switching to a different kernel would either mean all developers have to learn that language in addition to C++, making an additional barrier to entry in the project. Or, it would mean the team has to split, between kernel and userspace developers. Making it impossible to change a syscall if you find that userspace needs something different. Or, to fix userspace if you find that it is using the kernel incorrectly (instead of adding a workaround in the kernel). Especially if we would run different kernels on x86 and other architectures, now, you are moving compatibility problems to userspace. The job of the kernel is to provide an unified and abstract interface to the hardware, so that the other parts of the OS donât have to handle intricate details of the hardware behavior. If you decide to use two different kernels, now itâs up to the C library and other system libraries to somehow handle the differences between these two kernels. This results in a more complicated system that can only use the least common denominator, the feature set thatâs supported in both kernels. If you want to add something to the kernel, now you have to do it twice. This makes things harder to change.
You can ask any developer in the Linux world about this. They will tell you how the kernel has hacks to keep old libc versions working. How there are hacks in drivers specifically for X11 that has a bug for a dozen years that no one will fix. And so on.
Also, the Haiku kernel is ready to use several cores. There are x86 processors and machines with 16 or 32 cores and we handle that without any problems. I donât think there are many RISC-V machines with this many CPU cores at the moment. On ARM, you would find that only on very high-end systems. Also, most of Haiku is written in C++, there are maybe a few hundred lines of assembler code in total, probably even less. So, all the differences between RISC and CISC are not visible to us. Thatâs a problem for the compiler, and certainly not something that justifies using a completely different kernel.
Once again I am humbled by the detailed response to my counterfactual (if being kind) or somewhat ignorant ânavel gazingâ (if not!). We often talk about the legacy free design Haiku enjoys relative to linux and so forth, but sometimes these posts bring it home just what that means in practice.
As for Multiplix, I look forward to following its progress. Especially if it demonstrates the viability of languages not usually seen in the OS kernel. Makes a nice change from Rust which everyone else seems to be using nowadays.