On 9 April 2015 at 08:05, Antti Kantee <[email protected]> wrote: > 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.
If you want to match it up to frankenlibc: #1 platform is platform/* #2 core is franken/ with the MD (arch dep) bits in franken/ucontext #3 rumpuser is rumpuser/ #4 rumpkernel is rumpsrc/sys with buildrump.sh to build it #5 is the NetBSD libc from rumpsrc/lib/libc (I guess I could rename franken to core...) However there are some controlled layering violations - safe parts of libc that do not call into the rump kernel (eg memcpy) are now being used in platform and core, rather than the previous standalone implementation. #1-#5 are all wrapped into the libc that is produced to link applications against. Justin
