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?