News for hackers. Stuff that matters.
Re:Ask HN: What's a reasonable microkernel-based OS for desk... by snvzz on Monday September 11, 2017 @04:51PM (#15222211)
>I'm not sure an actual implementation buys you much over the NT approach.

As an introduction to that, I'd suggest reading https://en.wikipedia.org/wiki/MINIX_3#Reliability_policies

as most of that is tied to the pure microkernel multiserver approach, with strictly only the microkernel running in supervisor mode.

If you want to go into more depth, then I'm going to suggest

https://ts.data61.csiro.au/projects/TS/publications.pml

https://microkerneldude.wordpress.com/

And, of course, if what worries you is performance, then look into: http://blog.darknedgy.net/technology/2016/01/01/0/

Re:Ask HN: What's a reasonable microkernel-based OS for desk... by StillBored on Monday September 11, 2017 @05:48PM (#15222705)
I could point for each bullet point in your minux link how structuring your code like a microkernel (and a debug/instrumented build) solves the same problems, but I'm to tired to bother.

Lets just say, that in two decades of writing drivers and OS internals, i've shifted my opinions away from being a strong micro-kernel advocate toward a hybrid approach similar to what NT does.

Also, per you last link, i'm still one of the people who think virtualization and non zero copy syscalls adds too much overhead. Burning up 100% of a core to copy packets between userspace, the kernel, and then DMA'ing them to the device is pointlessly slow. Adding in a copies between kernel subsystems is worse and can't be avoided as easily as something like the NT registered I/O model. There are whole projects (dpdk for example) for which that single context switch/copy is to much too.

Re:Ask HN: What's a reasonable microkernel-based OS for desk... by snvzz on Tuesday September 12, 2017 @04:20AM (#15225666)
>but I'm to tired to bother.

By all means, do. As far as I can see, these do not work without the enforced isolation of running as userspace processes.

>Burning up 100% of a core to copy packets between userspace, the kernel, and then DMA'ing them to the device is pointlessly slow.

That's not how it usually works.