> Basically you should be able to modify an existing unikernel implementation to make it real time.
It's very very difficult to hack in real time properties after the fact. Most successful versions of this end up hacking in a virtualization layer to run the code that wasn't designed to be real time in the first place rather than trying to make that code play nice cooperatively with a real time system.
RTLinux is a good example which uses Linux to bootstrap a microkernel which then virtualizes the Linux kernel that booted it.
What kind of guarantees, mechanisms and instrumentation can unikernels provide in this space for real-time execution of code for mission critical systems?
At John Deere they compile various "applications" into their home-grown JDOS (or rather for a given controller, they compile several apps and the OS into a single 'executable'). I.e., the OS is a library, which I think is the definition of a unikernel, although perhaps not since there are often several apps on a controller?
Typically unikernels have a single application in them because then you can fully specialize the entire image to the needs of that single application. Having said that, it is entirely possible to place multiple applications in one unikernel, each in its own thread; we have done a few of these in the past.
It's very very difficult to hack in real time properties after the fact. Most successful versions of this end up hacking in a virtualization layer to run the code that wasn't designed to be real time in the first place rather than trying to make that code play nice cooperatively with a real time system.
RTLinux is a good example which uses Linux to bootstrap a microkernel which then virtualizes the Linux kernel that booted it.