3 ms·

I think you're post-rationalizing. The kernel is an exception today, true, but that doesn't mean it needs to be special. The established Unix philosophy of eve

I think you're post-rationalizing. The kernel is an exception today, true, but that doesn't mean it needs to be special. The established Unix philosophy of everything being "one program that does one thing" would be hugely beneficial if applied to an OS kernel. Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel? Not to mention that it could be much easier to develop them if they could just run as processes and die if they failed, as opposed to inducing a kernel panic.

cyphar 11y ago
> Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel? Except that it makes debugging almost impossible and the overhead of IPC is very large. I'd argue that most popular kernels today (k{Free,Open,Net}BSD, illumos, Linux) are monolithic because that model makes development much simpler than a microkernel (not for historical reasons). Hybrid kernels like NT are a compromise for efficiency against the benefits of having a microkernel. The panic argument is a good point, until you realise that kernel drivers don't panic --they oops. And a kernel oops just kills the thread it was running in. Linux has kernel threads that can be killed, but they're all playing in the same address space. So you can think of that as having the advantages of a microkernel without the debugging issues.
- JdeBP 11y ago
  IPC overhead applies to monolithic and micro kernels alike and is a general design issue, not a microkernel one. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/microkernel-conceptual-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/mi...
- lobster_johnson 11y ago
  Debugging would be easier in user mode, surely. You could attach with gdb or whatever. Last I checked, IPC overhead was not a barrier to performance in modern microkernels. QNX and XNU (used by OS X) both use microkernel-type IPC and are fast. XNU is even able to survive with an old Mach kernel. If a kernel driver ends up in a faulty state (accesses invalid memory, does the wrong interrupt thing) then surely the whole kernel will panic? NT is frequently referred to as "hybrid", but it's a frequently misunderstood design. First, while it uses IPC internally, it's not really comparable to microkernels since there's no context switch; every participant in the IPC communication is in the kernel. This is done purely as a way to isolate internals behind a rigorous, message-oriented API. Secondly, almost all of NT's services run in the kernel. A fairly small number of services run in userland: There's the user-mode driver system (UMDF, available since Vista), and graphics drivers also have the option of running partly in usermode.

cyphar 11y ago

> Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel? Except that it makes debugging almost impossible and the overhead of IPC is very large. I'd argue that most popular kernels today (k{Free,Open,Net}BSD, illumos, Linux) are monolithic because that model makes development much simpler than a microkernel (not for historical reasons). Hybrid kernels like NT are a compromise for efficiency against the benefits of having a microkernel. The panic argument is a good point, until you realise that kernel drivers don't panic --they oops. And a kernel oops just kills the thread it was running in. Linux has kernel threads that can be killed, but they're all playing in the same address space. So you can think of that as having the advantages of a microkernel without the debugging issues.

JdeBP 11y ago
IPC overhead applies to monolithic and micro kernels alike and is a general design issue, not a microkernel one. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/microkernel-conceptual-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/mi...
lobster_johnson 11y ago
Debugging would be easier in user mode, surely. You could attach with gdb or whatever. Last I checked, IPC overhead was not a barrier to performance in modern microkernels. QNX and XNU (used by OS X) both use microkernel-type IPC and are fast. XNU is even able to survive with an old Mach kernel. If a kernel driver ends up in a faulty state (accesses invalid memory, does the wrong interrupt thing) then surely the whole kernel will panic? NT is frequently referred to as "hybrid", but it's a frequently misunderstood design. First, while it uses IPC internally, it's not really comparable to microkernels since there's no context switch; every participant in the IPC communication is in the kernel. This is done purely as a way to isolate internals behind a rigorous, message-oriented API. Secondly, almost all of NT's services run in the kernel. A fairly small number of services run in userland: There's the user-mode driver system (UMDF, available since Vista), and graphics drivers also have the option of running partly in usermode.