Yes you're right, it's a simple network-like protocol allowing you to mount a path on the host OS to the Unikraft unikernel VM similar to a container volume. In addition, Unikraft's abstract APIs[0] allow for more block devices such as EXT{2..4}, etc. which you mount in a similar way. Alternatively, you can put your filesystem into a CPIO format and mount it as initram and load it into RAM (great for performance and read-only file systems, like webservers).
Systems research is more relevant than ever. You should take a look over the papers published at conferences such as SOSP, OSDI, EuroSys and HotOS. You'll see quite a lot of papers from industry giants. Lots of research OSs are also gaining traction[1][2][3]. I'd say that we're moving towards specialization right now, with a specific OS architecture for your usecase. OS research is far more than Linux right now.
"MirageOS [40] is an OCaml-specific unikernel focusing
on type-safety, so does not support mainstream applications,
and its performance, as shown in our evaluation, is sub-par
with respect to other unikernel projects"
> 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.
