Hacker News Reader

Comment by dkarapetyan | Hacker News Reader

I'm a little confused about the direction things are going in. I like high level languages and I like that the OS manages certain resources so I don't have to. This guy is writing directly to block devices from OCaml. Don't get me wrong it's all pretty cool but there is some kind of dissonance there I can't reconcile. Is Xen the new OS now?

View on HN

Note, though, that he is indeed writing to a block device--which is much higher-level than writing to a disk.

Remember back in the 80s, when the BIOS was actually an effective hardware abstraction layer--giving you a defined interrupt to ask the BIOS to, say, write to a disk--and the OS was just for module loading and scheduling and policy-based security? (Not that DOS did either of the latter.)

Well, Xen isn't the new OS; instead, the domU is the new BIOS, and hypercalls are the new BIOS interrupts.

I really hope to see Linux redone (or another *nix created) in this "unikernel" style, where everything hardware-like or HAL-like is taken out, and instead things like filesystem drivers are implemented directly in terms of hypercalls.

I also hope to see UEFI reimplemented as a resident domU, such that a plain old desktop or notebook computer could treat its user OS as a container-image to be slung around, rather than having it "own" the hardware. UEFI actually already supports this mode of operation--allowing you to boot "UEFI applications" that keep UEFI around to provide BIOS-like functionality--but I don't know of a single OS that makes use of that, rather than overwriting the processor interrupt vectors and claiming all of physical memory for itself.

>I also hope to see UEFI reimplemented as a resident domU, such that a plain old desktop or notebook computer could treat its user OS as a container-image to be slung around, rather than having it "own" the hardware. UEFI actually already supports this mode of operation--allowing you to boot "UEFI applications" that keep UEFI around to provide BIOS-like functionality--but I don't know of a single OS that makes use of that, rather than overwriting the processor interrupt vectors and claiming all of physical memory for itself.

This is really the opposite direction things are going, especially in x86_64. PV is horrendously inefficient in 64 bit mode, because of the removal of CPU ring 1 and 2.

http://wiki.xen.org/wiki/Virtualization_Spectrum#Problems_wi...

HVM allows PCI passthrough if your CPU and chipset support it, which means domU now has direct access to the hardware, with no dom0/qemu layer to get in the way and slow things down.

We have a feature issue tracking UEFI in Mirage, but noone's written the bootloader code yet: https://github.com/mirage/mirage/issues/187

Interestingly, it looks like the easiest way to support Azure...

Yes, basically. You let the host manage memory, disk, network etc and your program is a guest OS that doesn't need all the extraneous processes that usually go with a whole OS. No background services or cron jobs.

Edit: as enduser pointed out, in addition to saving resources, this means there is no context-switching from kernelspace to userspace in your guest VM!

You let the host manage memory, disk, network etc and your program is a [process] that doesn't need all the extraneous processes that usually go with a whole OS. No background services or cron jobs.

So it's like Docker.

No, this is fundamentally different from docker.

Docker/cgroups/namespaces allow you to isolate multiple applications running in userspace on the same kernel to a very high degree.

This gets rid of isolation and multiprocessing altogether and runs a single application without any kernel at all (i.e. with just a very limited amount of support code linked in).

Put simply; the technology behind docker improves isolation between processes and this does the exact opposite.

I don't see how this, "...does the exact opposite," of what Docker does—both are very different approaches to the similar goals of having individual processes run in isolated ways. Docker does it by isolating individual running Linux processes under a single kernel, whereas unikernel-based systems do it by building those processes as lightweight programs that get compiled to their own kernel images and then running those on a hypervisor to achieve isolation.

Yes, you are right, this is not a binary classification and it really depends on the perspective. What I was trying to say is that - on some levels - the two approaches are almost antithetical.

> This guy is writing directly to block devices from OCaml. Don't get me wrong it's all pretty cool but there is some kind of dissonance there I can't reconcile. Is Xen the new OS now?

For some applications removing this overhead might be interesting - e.g. databases tend to fight with the peculiarities in the host OS (scheduler, caching, disk access patterns).

The major upside of this approach IMO is the added robustness you get, since deploying turns into a very deterministic procedure, there's no underlying OS updates and whatnot to break your app.

Reply on news.ycombinator.com