4 ms·

So if I understand correctly, you end up with some sort of binary, that you can run on top of some system that abstracts away the hardware and manages resources

by pnako 7y ago

So if I understand correctly, you end up with some sort of binary, that you can run on top of some system that abstracts away the hardware and manages resources, correct?

rwmj 7y ago
You end up with a self-contained application binary which runs anywhere that you could run a Linux kernel. However it's different from embedding an initrd into a kernel image in several ways: The kernel is minimal, containing only the bits which are needed by your application or drivers required to run on the hardware. The application runs in kernel space and is linked with the kernel which gives you a nice performance boost because you never context switch (which is the driver behind the whole project actually). You can also call kernel functions which aren't syscalls, eg. for specialized memory management.
- 0x445442 7y ago
  64-bit DOS?
  - fock 7y ago
    but with permissions you can conveniently ovveride by default!
    - rwmj 7y ago
      It doesn't even make sense to think about permissions for unikernels. There is exactly one application running. The trust boundary is at the edge of this application/kernel/VM thing, not anywhere within it.
- ahoka 7y ago
  What's so wrong with the context switch? You need to have some anyway if you want threads in your unikernel.
  - eyberg 7y ago
    This is a common misunderstanding. There are many different types of context switching and you need the context (heh!) To compare apples to apples. Kernel to userland, thread to thread, process to process, kernel thread vs user thread, etc. It's conflated because different threading models and different kernel/userland separations exist. Generally speaking (in linux) threads perform much much faster than switching processes.
    - rwmj 7y ago
      This is right, and the other mistake people make is measuring just the context switch, and not the many hundreds of thousands of cycles after the context switch spent repopulating the cache.

by pnako 7y ago

So if I understand correctly, you end up with some sort of binary, that you can run on top of some system that abstracts away the hardware and manages resources, correct?

rwmj 7y ago

You end up with a self-contained application binary which runs anywhere that you could run a Linux kernel. However it's different from embedding an initrd into a kernel image in several ways: The kernel is minimal, containing only the bits which are needed by your application or drivers required to run on the hardware. The application runs in kernel space and is linked with the kernel which gives you a nice performance boost because you never context switch (which is the driver behind the whole project actually). You can also call kernel functions which aren't syscalls, eg. for specialized memory management.

0x445442 7y ago
64-bit DOS?
- fock 7y ago
  but with permissions you can conveniently ovveride by default!
  - rwmj 7y ago
    It doesn't even make sense to think about permissions for unikernels. There is exactly one application running. The trust boundary is at the edge of this application/kernel/VM thing, not anywhere within it.
ahoka 7y ago
What's so wrong with the context switch? You need to have some anyway if you want threads in your unikernel.
- eyberg 7y ago
  This is a common misunderstanding. There are many different types of context switching and you need the context (heh!) To compare apples to apples. Kernel to userland, thread to thread, process to process, kernel thread vs user thread, etc. It's conflated because different threading models and different kernel/userland separations exist. Generally speaking (in linux) threads perform much much faster than switching processes.
  - rwmj 7y ago
    This is right, and the other mistake people make is measuring just the context switch, and not the many hundreds of thousands of cycles after the context switch spent repopulating the cache.