On 01/02/16 22:30, Adam Wick wrote:
Is there some sort of size target you're trying to hit?
With the current HaLVM, "hello world" is around 2MB. So I'd like to get
down to around there. For larger programs, we regularly try to run VMs in
16MB containers, although it's probably more common to use 32MB ones.
With the rump kernel, my initial "Hello, World" was ~20MB. When I pulled
out a bunch of libraries (basically everything except rumprun.o, librump,
librumprun_base, librumpkern_bmktc, and librumpnonet_config) I got it down
to 10MB, and strip got it down to around 4. I'd love to shave off some
more, but that may be OK.
So are you measuring loaded footprint, not binary size?
I haven't paid too much attention to running in really low-memory
situations, so if you push that boundary, you might run into some
issues. If you do, please report. ...hmm, and one of these years I
probably should fix the 600+kB of unnecessary bss wastage that mato
found; when it's close to 5% of total memory, it might start hurting.
Rumprun shouldn't use the netconfig stuff. netconfig is a prehistoric
way to configure the tcp/ip stack on non-NetBSD systems, e.g. Linux
userspace, where you don't have access to NetBSD headers in any clean
way. Rumprun should configure networking using syscalls, which are
dynamically loaded at boottime, so you don't get symbol dependencies,
just a ENOSYS if you try to invoke a syscall which isn't present.
Hmmm. So should the relevant code in rumprun_base be updated, then? The
relevant problem file is lib/librumprun_base/config.c, and the chain of
events from the "net" parser / handle_net().
Yes.
Also note that the networking stack isn't really componentized, it's
just pretending to be. The NetBSD code has a lot of #ifdef INET/INET6
in there, so we just define both, and run the constructors depending on
what you link in. So, if you want to really remove either one, you need
to do a special build where you muck about with the contents of
src-netbsd/sys/rump/include/opt
Hmmm. OK. I'll take a look. I had hoped that just not including librumpnet
and friends (librumpnet_netinet, librumpnet_netinet6, etc.) would work. It
hasn't failed yet, at least. But I'll admit I hadn't looked at the
resulting symbols in my binary to see what was getting included.
Sorry, I wasn't clear. If you leave rumpnet* out, you don't get any
networking, as simple as that. I meant that if you want networking, but
only one of ipv4/6 (or an otherwise similar customization), for the time
being you need a custom build.
