3 ms·

>There is a lot of code in your monolithic OS kernel. This code is usually there for a reason and a unikernel will have to implement large swaths of this code

by zaarn 8y ago

>There is a lot of code in your monolithic OS kernel. This code is usually there for a reason and a unikernel will have to implement large swaths of this code anyway. Networking isn't trivial and I don't think anyone will be reimplementing the TCP/IP, UDP/IP, ARP, DHCP and more stacks without breaking in a few bugs themselves. Example, modern TCP congestion control requires a very precise packet pacing and timing. Another example, TCP retransmission will be required at some point, the code doing this will have to run side-by-side with the app. This will also be some amount of code. And all this just piles up and up. The only real advantage I see for unikernels is that because all the hard work is done by the hypervisor they don't have to bother implementing device drivers and task scheduling but end up either replicating or using the hypervisor's own networking stack and a bunch of other subsystems.

mato 8y ago
> This code is usually there for a reason and a unikernel will have to implement large swaths of this code anyway. The largest part of a monolithic kernel today is devices drivers, by far. > Networking isn't trivial and I don't think anyone will be reimplementing the TCP/IP, UDP/IP, ARP, DHCP and more stacks without breaking in a few bugs themselves. Sure. And then more people will use those stacks, and they will get better. The more the merrier, we have too much of a software monoculture anyway. > The only real advantage I see for unikernels is that because all the hard work is done by the hypervisor they don't have to bother implementing device drivers This. People continually underestimate the amount of work required to support the hardware ecosystem. This is also why rump kernels (note, not the same term as the unikernel known as Rumprun) are such an achievement, also very much underappreciated.
- zaarn 8y ago
  Well, yes, a lot is device drivers, but not most. You can make the Linux kernel, for example, minus almost all drivers. That usually slims down the kernel image by a few megabytes. More when you drop various other drivers and subsystems you technically no longer need. Though on most modern systems almost 80% of the drivers are modules and won't be loaded if not needed. The diskspace they consume is irrelevant for most intents and purposes (below 100MB on my distro). > The more the merrier, we have too much of a software monoculture anyway. Linux and some other kernels allow userspace apps to have their own network stack in userspace, latest kernels allow even larger sections of the networking subsystems to be entirely in userspace. I think this approach should be favored over a unikernel since it uses the natural x86 privilege seperation between userspace and kernel.

by zaarn 8y ago

mato 8y ago

> This code is usually there for a reason and a unikernel will have to implement large swaths of this code anyway. The largest part of a monolithic kernel today is devices drivers, by far. > Networking isn't trivial and I don't think anyone will be reimplementing the TCP/IP, UDP/IP, ARP, DHCP and more stacks without breaking in a few bugs themselves. Sure. And then more people will use those stacks, and they will get better. The more the merrier, we have too much of a software monoculture anyway. > The only real advantage I see for unikernels is that because all the hard work is done by the hypervisor they don't have to bother implementing device drivers This. People continually underestimate the amount of work required to support the hardware ecosystem. This is also why rump kernels (note, not the same term as the unikernel known as Rumprun) are such an achievement, also very much underappreciated.

zaarn 8y ago
Well, yes, a lot is device drivers, but not most. You can make the Linux kernel, for example, minus almost all drivers. That usually slims down the kernel image by a few megabytes. More when you drop various other drivers and subsystems you technically no longer need. Though on most modern systems almost 80% of the drivers are modules and won't be loaded if not needed. The diskspace they consume is irrelevant for most intents and purposes (below 100MB on my distro). > The more the merrier, we have too much of a software monoculture anyway. Linux and some other kernels allow userspace apps to have their own network stack in userspace, latest kernels allow even larger sections of the networking subsystems to be entirely in userspace. I think this approach should be favored over a unikernel since it uses the natural x86 privilege seperation between userspace and kernel.