On 27/02/15 10:35, Justin Cormack wrote:
I think you have created the worlds largest hello world ;)
I immediately managed to optimize its size from 2MB to 800kB by not linking
in file systems, the networking stack, etc. Arguably those are not needed
by your standard "hello world" application.
I was linking them in to test for bugs when running kernel threads
mainly... those are fixed now.
I don't think it is the world's largest hello world - glibc is a 1.8MB
dynamic library, so it is actually more lightweight to link in most of
NetBSD!
I'm not going to ask how large it would be if you'd statically link in
the kernel to run glibc...
I have prepared a branch for rumprun-posix which removes the
non-remote support. I think it is probably a good idea to merge this
as it makes the repo easier to understand and explain, and the bin-rr
commands were not that useful on a one-shot kernel. We could then
rename it rumprun-remote to reflect that purpose.
Ah, right, we have to have that discussion too. The mailing list hassle
made me forget. Let's do it in a separate thread, though.
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.
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?
