On Mon, Feb 1, 2016 at 11:50 AM Antti Kantee <[email protected]> wrote:

> On 01/02/16 19:27, Adam Wick wrote:
> > I've been playing around with combining the rump kernel with the HaLVM,
> and
> > have a few quick (I hope) questions, mostly in the service of trying to
> > minimize the amount of code I end up linking.
>
> 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.


> > (2) I was stripping down a rumpkernel image to try to get rid of as many
> > dependencies as possible, and ended up needing to write a
> > "librumpnonet_config" (note the "no"), in order to satisfy some
> > dependencies in librumprun_base.  It's obviously pretty simple, and I'd
> be
> > happy to send a pull request if you're interested, but another way to do
> it
> > would be with weak definitions in rumprun_base. Do you have a preference
> > between the two approaches? The functions in question are
> > 'rump_pub_netconfig_ipv6_ifaddr', 'rump_pub_netconfig_ipv4_gw', and
> > friends.
>
> 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().


> 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.

(Just to be clear, I'm using a custom rumprun-bake target that only
includes -lrumpkern_bmktc and -lrumpnonet_config.)


> So, while it would probably be possible to force a reference to the
> entry point of each driver and therefore convince the linker to slurp
> the code in, I don't know:
>         a) what sort of can of worms that would be
>         b) how much it would actually buy you
>

Got it. Will focus on other things.


- Adam

Reply via email to