Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Things are beginning to look a bit more like microkernels as time goes on.

Hypervisors typically are microkernels. The very first "hypervisor" was L4 in fact, with L4Linux.

Also, you're right that virtualization and containers are fulfilling the promises of operating systems. The problem of earlier OSes is that they didn't take security seriously enough. Modern hypervisors aren't much better at isolation than real microkernels like L4, KeyKOS and EROS. They're better than containers though.



> The very first "hypervisor" was L4 in fact, with L4Linux.

The term "hypervisor" was coined by Popek and Goldberg in 1974. L4 didn't appear until the 90s.


> Hypervisors typically are microkernels.

Except they have vastly different histories (look up IBM's VM) and uses and underlying technologies.

Here's a good post on the difference:

https://utcc.utoronto.ca/~cks/space/blog/tech/HypervisorVsMi...

> Microkernels are intended to create a minimal set of low-level operations that would be used to build an operating system. While it's popular to slap a monolithic kernel on top of your microkernel, this is not how microkernel based OSes are supposed to be; a real microkernel OS should have lots of separate pieces that used the microkernel services to work with each other. Using a microkernel as not much more than an overgrown MMU and task switching abstraction layer for someone's monolithic kernel is a cheap hack driven by the needs of academic research, not how they are supposed to be.

> (There have been a few real microkernel OSes, such as QNX; Tanenbaum's Minix is or was one as well.)

> By contrast, hypervisors virtualize and emulate hardware at various levels of abstraction. This involves providing some of the same things that microkernels do (eg memory isolation, scheduling), but people interact with hypervisors in very different ways than they interact with microkernels. Even with 'cooperative' hypervisors, where the guest OSes must be guest-aware and make explicit calls to the hypervisor, the guests are far more independent, self-contained, and isolated than they would be in a microkernel. With typical 'hardware emulating' hypervisors this is even more extremely so because much or all of the interaction with the hypervisor is indirect, done by manipulating emulated hardware and then having the hypervisor reverse engineer your manipulations. As a consequence, something like guest to guest communication delays are likely to be several orders of magnitude worse than IPC between processes in a microkernel.


> Except they have vastly different histories (look up IBM's VM) and uses and underlying technologies.

Microkernels over time have also employed vastly different technologies. All the "differences" you note are "intended system design/interaction", which frankly isn't meaningful. For instance:

> By contrast, hypervisors virtualize and emulate hardware at various levels of abstraction. This involves providing some of the same things that microkernels do (eg memory isolation, scheduling), but people interact with hypervisors in very different ways than they interact with microkernels.

Who cares how they interact with it? A microkernel is defined by the sorts of abstractions it provides and the isolation properties those abstractions entail. Hypervisors are effectively less expressive microkernels.


>"Using a microkernel as not much more than an overgrown MMU and task switching abstraction layer for someone's monolithic kernel is a cheap hack driven by the needs of academic research, not how they are supposed to be."

I found this interesting. Can you or anyone else say what the context was where academic researchers have needed to do this? What problem was it solving for them in a cheap way?


There is a linked article on his blog https://utcc.utoronto.ca/~cks/space/blog/tech/AcademicMicrok... that expands on this. Specifically:

>the whole 'normal kernel on microkernel' idea of porting an existing OS kernel to live on top of your microkernel gives you at least the hope of creating a usable environment on your microkernel with a minimum amount of work (ie, without implementing all of a POSIX+ layer and TCP/IP networking and so on). Plus some grad student can probably get a paper out of it, which is a double win.


This is a great read. Thank you.


Isn't the important thing about KeyKOS and EROS capabilities, and L4 variants aren't all capability-based, are they?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: