OSDev.org

Unikernels have apparently been around since the 90s, but I had never heard of them until a couple days ago.

Processes are isolated under a hypervisor, but what makes unikernels really unique is that the "operating system" is really just a collection of library files compiled together with the application. That means no privilege switching, which speeds things up (nearly 200%-300% under some loads).

Sounds more complex than something I want to tackle for a first OS; nevertheless, the concept is intriguing enough I figured anyone else who, like me, has apparently been out of the loop for 30 years, would like learning about it.

https://en.wikipedia.org/wiki/Unikernel

azblue wrote:Unikernels have apparently been around since the 90s, but I had never heard of them until a couple days ago.

Processes are isolated under a hypervisor, but what makes unikernels really unique is that the "operating system" is really just a collection of library files compiled together with the application. That means no privilege switching, which speeds things up (nearly 200%-300% under some loads).

Sounds more complex than something I want to tackle for a first OS; nevertheless, the concept is intriguing enough I figured anyone else who, like me, has apparently been out of the loop for 30 years, would like learning about it.

https://en.wikipedia.org/wiki/Unikernel

Allow me to re-phrase your definition of unikernel in a different way: the application is just bundled together with the OS code in one big bundle. Unikernels are loaded and boot more or less like other OSs, but they don't run multiple applications: the whole business logic (= application) is compiled directly in the kernel binary, no loading of extra code from disk etc. Some projects like #include <os> like to sell the idea that you're building your app + the OS as library, but it's merely a marketing thing to make look like the APP is in the center and everything else is built around it. Technically, it's the opposite: the app is the final piece of code that must be integrated in a whole "ecosystem". Anyway, both definitions are acceptable, I just wanted to share a different perspective on the same thing.

About your second point, let me say that unikernels are generally way simpler than classic OSs. Indeed, if you start writing an OS from scratch there be always a point when you can run some arbitrary C code from the kernel, but cannot load external applications yet. That would be an unikernel already. If you never go in the direction of adding syscalls & loading apps, but add features as plain functions, that would be it. Therefore, if you are intrigued by unikernels, go for it as your first OS, as it would be way simpler to implement than a classic UNIX-like OS

Hello Azblue,

azblue wrote:Unikernels have apparently been around since the 90s, but I had never heard of them until a couple days ago.

Processes are isolated under a hypervisor, but what makes unikernels really unique is that the "operating system" is really just a collection of library files compiled together with the application. That means no privilege switching, which speeds things up (nearly 200%-300% under some loads).

Sounds more complex than something I want to tackle for a first OS; nevertheless, the concept is intriguing enough I figured anyone else who, like me, has apparently been out of the loop for 30 years, would like learning about it.

https://en.wikipedia.org/wiki/Unikernel

I think unikernels did not show YET huge benefits in comparison with general purpose OSs like Linux that would fuel the adoption. There are many benchmarks (see unikraft website) that show the benefits in terms of performance. However, you will find limitations in terms of building system and portability. I think most approaches try to implement a POSIX-like unikernel. This is a huge work because you have to re-implement all the syscalls by conforming both syntactically and semantically. I agree that when it is done, you can always reuse it. In addition, applications run in ring-0 together with the kernel so if your app crashes, your VM becomes obsolete. This is not a huge issue since unikernels boot quickly so you can have your instance running again fast. However, I think it could be relatively easy to "poison" a unikernel to make it run what you want. I am not aware of this sort of attack though. Currently, unikraft is taclking this issue by adding user-space, i.e., ring-3.
In Toro Unikernel, I tried to build the architecture by bearing in mind how to improve it if the unikernel would run a single -possibly multithreading- application. The API still looks like POSIX BUT the whole architecture is shared-nothing.

Cheers,