5 ms·

1. We build unikernels using the 'kraft container' which is Docker/OCI image[0][1] which has the necessary build tools to build Unikraft unikernels. We plug th

1. We build unikernels using the 'kraft container' which is Docker/OCI image[0][1] which has the necessary build tools to build Unikraft unikernels. We plug this into Concourse CI which builds thousands of combinations of Unikernels[2] as part of our code review process[3]. In addition to this, we have on-going research and tooling to help automatically discover permutations of Unikernel builds[4]. We then run the unikernel natively using the target platform/hardware combination or use QEMU emulation. 2. Really great question, but mostly you can expect the same functionality of an application when it runs as a unikernel because the application "thinks" it's still running in a traditional OS environment -- as it should be. Check out this documentation[5] (after step 7) about porting, it has snippets about where the boundary sometimes breaks. Even then, you can run it in POSIX-compatibility mode[6]. 3. Well, general-purposes are not suited for deployment environments (which is what Unikraft is suited for). Installing Gentoo (or Ubuntu, Debian, for that matter) is a waste of resources if you only SSH in once to install your desired application. [0]: https://unikraft.org/docs/usage/install/#docker https://unikraft.org/docs/usage/install/#docker [1]: https://github.com/unikraft/kraft/tree/staging/package/docker https://github.com/unikraft/kraft/tree/staging/package/docke... [2]: https://builds.unikraft.io https://builds.unikraft.io [3]: https://unikraft.org/docs/contributing/review-process/#stages-of-the-code-review-process https://unikraft.org/docs/contributing/review-process/#stage... [4]: https://github.com/lancs-net/wayfinder https://github.com/lancs-net/wayfinder [5]: https://unikraft.org/docs/develop/porting/#providing-build-files https://unikraft.org/docs/develop/porting/#providing-build-f... [6]: https://unikraft.org/docs/features/posix-compatibility/ https://unikraft.org/docs/features/posix-compatibility/

ryukoposting 5y ago
I edited my comment to clarify this, but I meant "general-purpose OS" in a very broad sense - i.e. not much more than "can it load, execute, and time-share between arbitrary programs loaded from an attached storage device." Thanks for the links!
- nderjung 5y ago
  The application code is compiled along with kernel code so you can think of unikernels as a single-process VM, there's nothing else running other than the application so it boots straight to `main()`. Unikraft just facilitates the runtime of the application to be able to run as a VM or on baremetal. There's no shell, so you can't instantiate another program from disk. If the application wishes to read and write from an attached storage, it can, but it can't start another process if it's reading application code to-be-executed. Starting another process is a bit tricker since there is no `fork()` to execute another process. Interesting work is being done to enable multi-threading across cores via SMP[0] however and to provide fork like ability but with regard to the application's logic[1] but not in a wider general multi-processing environment. I hope this clarifies things. [0]: https://github.com/unikraft/unikraft/pull/244 https://github.com/unikraft/unikraft/pull/244 [1]: https://xen2021.sched.com/event/jAME/cloning-unikernels-on-xen-costin-lupu-university-politehnica-of-bucharest https://xen2021.sched.com/event/jAME/cloning-unikernels-on-x...
  - ryukoposting 5y ago
    I'm familiar with unikernels as a concept - heck, I wrote (a bad) one for a research project during my undergrad with embedded systems and softcore processors as the target. It's exciting to see unikernels being used with software of a similar scale, but with a much more broad solution space.

ryukoposting 5y ago

I edited my comment to clarify this, but I meant "general-purpose OS" in a very broad sense - i.e. not much more than "can it load, execute, and time-share between arbitrary programs loaded from an attached storage device." Thanks for the links!

nderjung 5y ago
The application code is compiled along with kernel code so you can think of unikernels as a single-process VM, there's nothing else running other than the application so it boots straight to `main()`. Unikraft just facilitates the runtime of the application to be able to run as a VM or on baremetal. There's no shell, so you can't instantiate another program from disk. If the application wishes to read and write from an attached storage, it can, but it can't start another process if it's reading application code to-be-executed. Starting another process is a bit tricker since there is no `fork()` to execute another process. Interesting work is being done to enable multi-threading across cores via SMP[0] however and to provide fork like ability but with regard to the application's logic[1] but not in a wider general multi-processing environment. I hope this clarifies things. [0]: https://github.com/unikraft/unikraft/pull/244 https://github.com/unikraft/unikraft/pull/244 [1]: https://xen2021.sched.com/event/jAME/cloning-unikernels-on-xen-costin-lupu-university-politehnica-of-bucharest https://xen2021.sched.com/event/jAME/cloning-unikernels-on-x...
- ryukoposting 5y ago
  I'm familiar with unikernels as a concept - heck, I wrote (a bad) one for a research project during my undergrad with embedded systems and softcore processors as the target. It's exciting to see unikernels being used with software of a similar scale, but with a much more broad solution space.