Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)
- From: Antti Kantee <pooka@xxxxxx>
- To: wei.liu2@xxxxxxxxxx
- Date: Mon, 28 Sep 2015 17:36:49 +0000
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.
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.
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).
- antti
Other related posts:
- » rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Martin Lucina
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Wei Liu
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Wei Liu
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible) - Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Wei Liu
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Wei Liu
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Martin Lucina
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Justin Cormack
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Martin Lucina
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Justin Cormack
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Krishna
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Justin Cormack
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Martin Lucina
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Krishna
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Justin Cormack
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Krishna
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Justin Cormack
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee
- » Re: rump{bake,run} configuration files (Re: Make rumpbake more flexible)- Antti Kantee