On 27/02/15 12:59, Justin Cormack wrote:
On 27 February 2015 at 10:50, Antti Kantee <pooka@xxxxxx> wrote:I don't actually know what to call frankenlibc - that was only the working title...Like I posed on irc, should frankenlibc be a public API, or is it just some internal magic which makes rumprun-posix work? If the latter, I think frankenlibc name is not too bad.True, but the thing in front is not "posix", as there are specific backends, currently Linux, NetBSD.
True. However, I'd rather call the product something familiar and meaningful to users, even if slightly technically incorrect, as opposed to inventing a new term.
Actually, we could think of a standard names for the "firmware" components in the rumprun stack, i.e. the layer under rumpuser which consists of both common bits (scheduler, memory allocator, ...) and platform-specific bits (minios, bmk, frankenlibc). Anyone feeling creative?I am starting to divide stuff up more cleanly in frankenlibc as part of the cleanups I am doing. The generic malloc is in the libc/generic code, while page allocation is per platform. I have just pulled the scheduler out of librumpuser into libc/thread, although the mutex code needs splitting out still to abstract it a bit better. This means that librumpuser is not exposing threading stuff which should make the _lwp support nicer as it will be using internal interfaces. So the structure is librumpuser -> frankenlibc -> platform although currently frankenlibc generic and platform are built into the same libfranken.a, but they are split in the code (libc/linux and libc/netbsd is the platform code).
Right, so in your terminology "frankenlibc + platform" is what I called "firmware".
Note also buildrump.sh/bmk-common. I have some more unpushed changes for bmk-common, though, like I wrote earlier, I'm not determined if I got them right enough push them.
But we still need some official names.