6 ms·

Well, according to Tanenbaum, Windows is a hybrid too: „Windows NT 3.1 was a half-hearted attempt at a microkernel system, but it wasn’t done right and the perf

by rffn 9y ago

Well, according to Tanenbaum, Windows is a hybrid too: „Windows NT 3.1 was a half-hearted attempt at a microkernel system, but it wasn’t done right and the performance wasn't good enough on the hardware of the early 1990s, so it gave up on the idea for a while.“ http://www.cs.vu.nl/~ast/reliable-os/ http://www.cs.vu.nl/~ast/reliable-os/ The newest Windows version the article mentions is Vista. I am not aware though of such fundamental changes to the Windows kernel as would be needed to make it a true micro kernel.

StillBored 9y ago
Its a "hybrid" because its designed to behave and look like a micro-kernel, but instead of full subsystem/process isolation, all of the kernel subsystems exist in a single address space (although I guess this could be argued in the context of hyper-v not to be entirely true). This means that instead of incurring a full context/privilege switch just to pass messages between components, the messages go through (say the IO manager with an IRP) the subsystem controllers with simple function calls and effectively shared data structures (although its designed not to look that way). Because its compartmentalized like this, it would actually surprise me if somewhere in MS research/etc they don't have a full context switching version of the kernel running. Such a project would if nothing else help to catch "bugs" and validate the subsystem and drivers aren't misbehaving. Of course driver verifier achieves most of this goal by itself with simpler checks. OTOH, while the idea of a micro-kernel helps to solve a lot of development/design issues I'm not sure an actual implementation buys you much over the NT approach. That is, while its easy to say "just restart the storage subsystem" implementing something that is capable of getting the state right in a microkernel environment sufficiently that a bug which takes down a critical subsystem isn't repeatably fatal (or just drops important filesystem updates/whatever) likely creates even more complexity in which latent bugs can hide. Particularly in the face of buggy hardware where the driver is trying to avoid/work around a hardware misbehavior, doing something like restarting a disk controller won't necessarily unwedge a stuck command queue in the hardware. So, that said, I think if you keep the crappware (most "security" software for starters, maybe certain GPU drivers too) off a windows system its really rare to have windows crash. In the past 15 years I can't actually remember the last crash I saw on a machine running only WHKL qualified drivers, and i've never seen a crash on a server core machine.. etc...
- snvzz 9y ago
  >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 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://ts.data61.csiro.au/projects/TS/publications.pml https://microkerneldude.wordpress.com/ 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/ http://blog.darknedgy.net/technology/2016/01/01/0/
  - StillBored 9y ago
    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.
    - snvzz 9y ago
      >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.

by rffn 9y ago

StillBored 9y ago

Its a "hybrid" because its designed to behave and look like a micro-kernel, but instead of full subsystem/process isolation, all of the kernel subsystems exist in a single address space (although I guess this could be argued in the context of hyper-v not to be entirely true). This means that instead of incurring a full context/privilege switch just to pass messages between components, the messages go through (say the IO manager with an IRP) the subsystem controllers with simple function calls and effectively shared data structures (although its designed not to look that way). Because its compartmentalized like this, it would actually surprise me if somewhere in MS research/etc they don't have a full context switching version of the kernel running. Such a project would if nothing else help to catch "bugs" and validate the subsystem and drivers aren't misbehaving. Of course driver verifier achieves most of this goal by itself with simpler checks. OTOH, while the idea of a micro-kernel helps to solve a lot of development/design issues I'm not sure an actual implementation buys you much over the NT approach. That is, while its easy to say "just restart the storage subsystem" implementing something that is capable of getting the state right in a microkernel environment sufficiently that a bug which takes down a critical subsystem isn't repeatably fatal (or just drops important filesystem updates/whatever) likely creates even more complexity in which latent bugs can hide. Particularly in the face of buggy hardware where the driver is trying to avoid/work around a hardware misbehavior, doing something like restarting a disk controller won't necessarily unwedge a stuck command queue in the hardware. So, that said, I think if you keep the crappware (most "security" software for starters, maybe certain GPU drivers too) off a windows system its really rare to have windows crash. In the past 15 years I can't actually remember the last crash I saw on a machine running only WHKL qualified drivers, and i've never seen a crash on a server core machine.. etc...

snvzz 9y ago
>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 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://ts.data61.csiro.au/projects/TS/publications.pml https://microkerneldude.wordpress.com/ 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/ http://blog.darknedgy.net/technology/2016/01/01/0/
- StillBored 9y ago
  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.
  - snvzz 9y ago
    >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.