On 09/04/15 07:21, Justin Cormack wrote:
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.
What is the benefit of re-adding the laying violations that just have
been fixed? (well, mostly fixed, still some left in platform/xen)
The duplicated code is very minimal: ~6 str/mem routines and eventually
atomic CAS (MD). I'd rather just copypaste those than again make it
impossible to reason about which bits go where and what can get
accidentally used. The routines probably even could be just built from
src/common like libkern, objcopied into the correct namespace, and be
done with it. But used implicitly from libc without any guarantees of
what's going to happen when they're called or making it possible to
#include anything form userland namespace in layers <5: no.
#1-#5 are all wrapped into the libc that is produced
to link applications against.
That's a build system detail which is a trade-off between flexibility
and simplicity. It might be a genius approach or a disaster. I don't
yet know which one it is, but definitely will keep an open mind towards it.
