On 09/04/15 05:55, Hajime Tazaki wrote:
Hi Antti,
I drew a figure to try to understand the picture.
https://www.dropbox.com/s/8ccu3dqq5vwodts/rumpkernel.gif?dl=0
Very helpful, thank you.
#0 does not have to be "hardware", it can also be "cloud" or "userspace"
or whatever. Though, of course, eventually there will be hardware in
the stack ;)
#2 is mostly MI. The MD bits are those that interface with the CPU ISA,
as opposed to #1 which interfaces with #0. Like I wrote in the
original, it's a bit weird, since #2 MD bits are conceptually lower
layer than #1, but they are commonly shared over many #0's (e.g. x86 Xen
or bare metal), so just lumping them into #2 saves from having to define
another layer for no currently obvious functional purpose.
That picture would be useful on the rumprun repository wiki page,
especially combined with concrete references to the code, to help people
who want to understand the code layout.
At Sun, 05 Apr 2015 23:38:24 +0000,
Antti Kantee wrote:
The other separation we gain is independence between the rumprun
unikernel and the rump kernel. Yes, that makes sense ;)
I think I'm not understanding what is rumprun + unikernel
here. Is rumprun unikernel #3 + #5 + #6 or something else ?
While I am not sure about the exact definition of the term "unikernel"
-- I did look for the definition briefly a few weeks ago, but didn't
find anything really definitive -- in my interpretation "unikernel" is
what you get when you link all of #[1-6] into a single binary which runs
in a single address space.
I think I need to search the unikernel papers more thoroughly, and if
the definition is still elusive, see if can coax it out of Anil.
