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
