4 ms·

Honest question: why use a unikernel on bare metal? I can see the lure on top of an hypervisor. You already have an actual kernel running which you can use it

• toast0 6y ago
  Why pay the performance price of a full kernel in your machine if you are only going to run one application? I'm not the author, but running on bare metal is more fun than running in a hypervisor. And removing layers from your stack lets you see what the cost and value of the layers are. I've only done bootstrapping on x86 and 8-bit processors (which is just set your reset vector), but x86 has a lot of isoterric setup stuff, and learning about the magic is interesting, if not totally useful. Also, some runtime environments have a lot of manageability within; probably less than an OS, but maybe enough. Not sure about Go.
  • vbezhenar 6y ago
    One reason to avoid bare metal is drivers. There is a lot of hardware around. New hardware is released every day. And you need to write and maintain drivers for that hardware. That's a tremendous effort and hardware manufacturers usually write drivers for a very few operating systems and Go unikernel certainly won't be one of them. Using virtualization provides a simple common layer, so host operating system can deal with drivers and guest operating system can deal with more interesting things.
    • toast0 6y ago
      Of course you'll need to write a OS specific driver for critical hardware like interrupt controllers and system timers, but drivers for other things like network cards and disk controllers can be reused if you adopt the other OS's interfaces. Things like ndiswrapper exist to use windows drivers on Linux or FreeBSD; Linux, FreeBSD, and NetBSD also have a large pool of drivers, which can be used depending on which system's driver model you like best.
      • voltagex_ 6y ago
        Let's say I grabbed the e1000 driver from Linux, how much of the Linux kernel would I end up re-writing (badly)?
        • Koshkin 6y ago
          Why not just grab some other parts of Linux? Or, better yet, link your application right into it?
        • toast0 6y ago
          I haven't done it, and the e1000 driver is pretty big, so it's hard to scan quickly, but the general shape is you'd need to support the kernel functions the driver calls, and setup compatible kernel structures for the driver. At least the parts of the driver you call. Things like kernel malloc to setup pages and what not, mapping the device address, allocating interrupts, DMA (maybe), PCI, logging, maybe locking, basic c library stuff (memcpy etc). Some of those, you can probably just stub out, but some if it you have to do (badly or not). Some of that you probably need or want to build anyway. It's a fair bit of work, but if you want to support a lot of hardware, it's probably less work than porting a bunch of drivers.
          • voltagex_ 6y ago
            The e1000 came to mind because it's a commonly emulated network card. I wonder now what is more common in real servers.
            • toast0 6y ago
              e1000 is pretty common in servers, too. It's got a lot of variations though, which makes the full driver pretty big. virtio-net is a lot easier to write a driver for, of course. :)
  • truncate 6y ago
    How much benefit would it be over stripping an existing kernel, e.g. Linux/BSD, remove all modules that you don't need, tune schedulers for one application etc?
    • toast0 6y ago
      Hard to say, you'd really need to do both well to compare. Depending on the unikernel design though, you can significantly reduce user/kernel context switches beyond what you can with a tuned general purpose OS, potentially to the point of always sitting in ring 0. How much difference that makes, of course depends on your application and the quality of your various kernels.
• SAI_Peregrinus 6y ago
  Embedded definitely uses unikernels a lot (though often with the term "Library OS" for any OS that's statically linked to the single application it runs). Hypervisors add overhead that you often can't afford on a microcontroller.
• msla 6y ago
  Ideally, running on a hypervisor is absolutely identical to running on bare metal, and any difference the guest can detect is a bug in the hypervisor and/or the hardware. That was the value proposition of CP-40 back in the 1960s, right down to being able to run newer versions of CP (later called VM) as a guest on older versions, in order to develop and debug the next generation of hypervisor in a known-good environment which is, again, utterly indistinguishable from running on bare metal. https://en.wikipedia.org/wiki/IBM_CP-40 https://en.wikipedia.org/wiki/IBM_CP-40 I wonder how long it'll take the rest of the world to achieve that.
• eyberg 6y ago
  We fully expect and are planning for multi-tenant applications on devices similar to a rpi4 looking at the future so I firmly agree that flashing the device isn't really desirable. As an example if you have image inferencing project you might have a compute stick co-processor plugged in one slot and a camera in another. You might have a webapp as one application and ffmpeg in another. No reason not to isolate them as individual unikernels. Also, there's the case that one software team might have written one of those apps and a different team wrote the other.
• andy_threos_io 6y ago
  Embedded systems are bare metal. There are tons of usage. Bare metal can be anything from a 8bit microcontroller to multicore Ghz system. Every modern RF modem has a cpu, and uses some kind of unikernel or rtos, if you have smartphone You have at least one such a system running.