On 01/02/16 19:27, Adam Wick wrote:
Hello everyone -
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?
(1) Is there a guide somewhere that describes (at least briefly) what each
library in the rumpkernel (rumprun_base, rump, rumpkern_bmktc, rumpdev_bpf,
etc.) is supposed to do? Some of them I can guess by the name (rumpdev_bpf,
for example), but others are a bit more opaque. I can try to start putting
one together somewhere, if not.
You'll catch most of them by running "rumpmake rumpdescribe" in
src-netbsd/sys/rump. I've been planning to put a snapshot of the output
up on the wiki. Now I had an excuse:
http://wiki.rumpkernel.org/Info:-Available-rump-kernel-components
The rumprun-specific ones aren't listed there, though.
(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.
The dhcp client might take a bit of work. In related news, I'm really
hoping that we get a completely different dhcp client for somewhere
else, preferably one which isn't twice-mangled by myself.
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
(4) There's a lot of --whole-archive thrown around in the linker files. Is
trying to get rid of these a fight worth attempting, or have you already
tried and I should just give up now and trust 'strip' to help me later? (A
conclusion I'd like to avoid, as I don't want to get rid of debugging
symbols, just dead code.)
Well, yes and no. There's probably not a whole lot of dead code inside
the rump kernel, at least in a manner where you can determine the code
to be dead by static symbol analysis alone. Now, due to the way the
components are linked, the linker doesn't "see" that they are in use.
So, if you remove --whole-archive, the relevant drivers don't attach,
because the linker removes them.
Furthermore, the kernel code isn't structured like libc where one
interfaces is placed in one source file, so the granularity of dead code
g/c would be quite large and therefore improbable. (or maybe the linker
has gotten smarter since 1960, I don't know)
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
I think that's it for now. So far this has been a pretty smooth transition,
and I'm really excited about some of the capabilities it brings. I'm just
trying to make sure I hit a couple big issues (like binary size) early, to
make sure I'm not surprised by them later.
Cool, thanks for the update.
