Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)

  • From: Wei Liu <wei.liu2@xxxxxxxxxx>
  • To: Antti Kantee <pooka@xxxxxx>
  • Date: Tue, 29 Sep 2015 15:40:01 +0100

On Mon, Sep 28, 2015 at 05:36:49PM +0000, Antti Kantee wrote:

On 28/09/15 16:35, Wei Liu wrote:
I notice you've pushed relevant code. But I deliberately try to not look
at the implementation before commenting on this. I hope this can provide
some insight on how a normal user interprets this email.

Good idea!

To control the configs, add or remove elems from them. An elem is simply
passed as-is to the linker, so you can use e.g. -lfoo, /path/to/obj.o or
-L/mydir. However, you cannot specify the order.


Not sure what "you cannot specify the order" means. Do you mean I can't
specify then order of libraries / archives? If so, may I ask why is
there such restriction?

My concern is that some linker (GNU ld at least?) cares about the order
of archives. What is the proper solution for that?

Does it make sense to make all objects / archives / libraries appear in
the order of them being added by backconf_elem_add?

It's convenient to specify building blocks as "self-contained" units, so for
example ipv4 and ipv6 both end up containing the networking components,
virtio and usb end up containing pci, and so forth. If you don't filter out
dupes, you get link errors. The filterer doesn't know which one it should
leave, and while we could come up with rules such as "last dupe remains",
IMO it would affect usability rather negatively while not guaranteeing
correctness, and therefore it's easier to say the order is unspecified.

The rump kernel components are linked with --whole-archive, so order
shouldn't matter. If someone can demonstrate a problem where it does
matter, we need a different approach/specification.


Right, order shouldn't matter. That addresses my concern.

My original interpretation was "order matters but you don't have
control" which was a bit weird TBH. :-)

I would have just written "order doesn't matter" if I were writing end
user document.

bakeconf_elem_add hw_coolbeans /home/pooka/startmsg.o

This "startmsg.o", is it just a normal application object or quasi
rumpkern object (an object that uses rump kernel api etc)?

I think in theory I can add any random object here, but it might be
better to at least say in document that you're supposed to only add
quasi rumpkern object?

startmsg.o is this source module:

=== snip ===
#include <stdio.h>

static void __attribute__((constructor))
flop(void)
{

printf("it's alive!\n");
}
=== snip ===

compiled with x86_64-rumprun-netbsd-gcc -c -o startmsg.o flop.c

Not sure if that's what you mean by "quasi rumpkern object" or not. But I
think it should be obvious that you can only link compatible object files,
and we don't need to explicitly enumerate e.g. that you can't link ARM
objects into an x86 Rumprun stack.


I didn't expect to be able to link ARM object to x86 stack. I was
talking more about what is the good practice to decide whether I should
put an object in my customised conf or explicitly link it against my
application code in my main build system.

For example, in my current code, I use rune like (in old syntax)

./rumpbake -c customised_conf xen_pv_qemu init_obj app_obj

init_obj is an object that contains code to bring up the platform to a
specific state.

With the new syntax, I guess you're advocating I put init_obj in
customised_conf.

Note! The config file syntax is not intended to have shell syntax. It's
just an implementation detail. Not sure if we at some point want to
implement the same in !shell.


Let's cross the bridge when we get there. As long as we're strictly
extending the syntax we're fine. This is my two cents.

The intent is to leave enough material so that building a bridge is possible
;)

soon now. We still need to figure out how various configs map to various
build targets (e.g. hw_generic does not make sense for ARM), though.


I think this is orthogonal to coining the syntax and semantics. More an
internal implementation issue?

Not really, because if we assume "bakeconf_assimilate myconf hw_virtio"
works, the name "hw_virtio" must remain stable, or we just drag some
backward-compatible aliases along. It's easier to just try to do it at
least foreseeably right before pronouncing things stable (it's a different
matter if we actually get it right, but IMO compat is for fixing unforeseen
mistakes, not for fixing foreseen ones).


I don't have good idea how to proceed. But as you mentioned, there is
always last resort solution of have backward-compatible aliases.

Wei

- antti

Other related posts:

  1. Home
  2. rumpkernel-users
  3. Archive
  4. 09-2015