Re: frankenlibc preview
- From: Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx>
- To: Antti Kantee <pooka@xxxxxx>
- Date: Fri, 27 Feb 2015 12:59:29 +0000
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.
> 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).
Justin
Other related posts:
