Ah, another microkernel-based hobby operating system. The more, the merrier – and I mean this, without a hint of sarcasm. There’s definitely been a small resurgence in activity lately when it comes to small hobby and teaching operating systems, some of which are exploring some truly new ideas, and I’m definitely here for it. Today we have managarm.
Some notable properties of managarm are: (i) managarm is based on a microkernel while common Desktop operating systems like Linux and Windows use monolithic kernels, (ii) managarm uses a completely asynchronous API for I/O and (iii) despite those internal differences, managarm provides good compatibility with Linux at the user space level.
↫ managarm GitHub page
It’s a 64bit operating system with SMP support, an ACPI implementation, networking, USB3 support, and, as the quoted blurb details, a lot of support for Linux and POSIX. It can already run Weston, kmscon, and other things like Bash, the GNU Coreutils, and more. While not explicitly mentioned, I assume the best platform to run managarm on are most likely virtualisation tools, and there’s a detailed handbook to help you along during building and using this new operating system.
Asynchronous IO is awesome! I’ve been critical of the lack of asynchronous IO constructs in the linux kernel for a long time. It was built when blocking IO was the norm for applications (multiprocess or multithreaded). But as asynchronous programming was embraced at the application level, the linux kernel still needed to convert it back into threaded model that linux drivers are based on.
This design has severe repercussions because unlike with asynchronous programming, data structures and processes cannot be deleted/killed until the kernel threads return. These threads only return when outstanding IO succeeds or fails, but when the source medium freezes (not returning an error nor success), so does the kernel thread. This is why linux network file systems and sometimes usb drives lock up and the tasks waiting for IO cannot be killed, even when an administrator issues “kill -kill pid”. The process goes into a “Dead” state but it cannot be completely killed until pending IO is complete.
https://unix.stackexchange.com/questions/364100/why-cant-we-kill-uninterruptible-d-state-process
https://stackoverflow.com/questions/223644/what-is-an-uninterruptible-process
Anyone who’s encountered this knows how infuriating it is! For me it has resulted in editors like kedit freezing in the “dead” state and not being killable. Even when you try to reboot, the system can lock up for minutes at a time waiting for dead kernel threads to eventually time out. Ugh.
It wouldn’t be an issue with an asynchronous kernel. Of course, we’re all still going to use linux anyway, but I say bravo for doing something different!
Looks really nice. I understand it has different goals than Gnu HURD, but this is what I kind of imagined happening years ago. Userspace stays the same, kernel is swapped out. users really don’t notice much difference. I’m sure there are all kinds of hiccups and things that don’t work or are wonky here and it hasn’t been battle tested for reliability or security, but its very impressive, IMHO. Planning on taking it for a spin later tonight.
1st, define synchronous regarding OS…
is this a tick-based operation?
How would you schedule without it?
2nd, there’s absolutely nothing new or unique in being interrupt based.
3rd, What have you sacrificed under the title of ‘pragmatic’ then?
4th, was there a challenge in principle of computer-science that you phrased and/or solved?
https://mapsdrivingdirections.io