On 27/05/15 09:12, Martin Lucina wrote:
On Wednesday, 27.05.2015 at 07:19, Antti Kantee wrote:
That said, referring to my mail in the "Xen on PV AWS" thread, we
still need to figure out if the component configuration is a "build"
thing or a "rumpbake" thing. In other words, is the board name
necessary for the toolchain, or is it just a parameter to rumpbake?
So at least some thinking is required.
Conceptually it's not necessary. However I don't see any way of
implementing it.
What is not conceptually necessary? (typo? paragraph seems incoherent)
There is no difference in the userspace *compiler* toolchains for different
boards. i686-rumprun_hw_generic-netbsdelf-cc generates the exact same code as
i686-rumprun_hw_virtio-netbsdelf-cc. In fact, I'm about 80% sure that these
generate the exact same code as i686-rumprun_xen_pv-netbsdelf-cc. If I'm
right, then we only need a single CPU-rumprun-whatever toolchain to build
the userspace application.
Ok, so "it" == "board name in toolchain tuple". Yes.
How hard can it be? We replace ld with a script that:
1) records the parameters passed to it to the target file
2) calls real_ld with those arguments with a minimal component
config to test that the "userspace" side links, and throws away the
result
And, for real linking (rumpbake) we look up the arguments from the
file and use the full component configuration for the target.
Anyway, I need to play around with it. I already forgot why I
haven't done so yet.
*Inspiration* I thought about throwing away the result, not sure why I
discarded that option. That might work.
I've played around briefly. What I think we want is:
Does that statement mean that you have working code or you played around
with it in your head? You read like an academic paper where one can
never be quite sure if they're describing something that works or works
on paper ;)
1) two sets of compiler specs, "ferment" and "bake".
ROFL! Good that I finished my coffee a few minutes earlier.
2) the userspace ld (well, gcc) uses the "ferment" specs and performs the
following steps:
a) ld -r -o <target file> <userspace objects and libraries>
b) real_ld -o /tmp/whatever <target file> <minimal rump components>
c) if b) failed, stop.
3) rumpbake performs the following steps:
a) real_ld (using "bake" specs) -o <unikernel image> <target file from step 2a>
<selected rump components> ...
For step 2b) to work correctly we'll need to make some parts of
librumprun_base weak (at least _rumprun_(de)config) and link in stubs to
avoid pulling in -lrumpnet*.
The reason step 2a) uses ld -r is that otherwise in step 3a) we'd need to
be sure that all of the application object files and libraries are still
present and identical.
Since step "3" is handled by "rumpbake", not "cc", we don't have to use
ld at all for "2a". Not sure if not using ld will make it unnecessarily
difficult to extract everything that needs to be saved, though, but can
keep that option open.
For additional kudos, step 2a) can link in some kind of fake object file
describing the output so that rumpbake can tell whether or not what you're
baking is compatible with what you fermented :)
It can be for example a tarball with some text padding.
From the user's point of view the process would look like this:
i686-rumprun-netbsdelf-gcc -o hello hello.c
rumpbake -T i686-generic -o hello.bin hello
rumprun kvm ./hello.bin
Thoughts?
Looks generally good.
Why do you need i686 for the -T argument to rumpbake? Did you mean e.g.
hw-generic instead?
I assume there will be something like "rumpbake -T list". How does one
add targets? .rumpbakerc? -c rumpbakelist?
How are multiple programs handled? You probably give multiple binaries
to rumpbake, but then how do you decide in which order they run? That's
probably a rumprun thing, but how do you remember which "executables"
have been baked?
Where is the configuration file handled?
The default would be what the compiler generates, no? If we don't
want to probe it, due to how many cans of worms it may open, i686 is
a safer default. Are 486-based embedded industry computers still a
thing, i.e. can we with non-zero confidence expect to never run into
one?
Given how slowly the embedded world moves, probably not. eg. The soekris
board I want to try things on is a 486-class CPU.
IOW, we can't hardcode the toolchain target to i686.
Looks like it's quite easy to probe, though:
pooka@watou:~$ cc -m32 -E -dM - < /dev/null | grep i.86
#define __i686 1
#define __i686__ 1
#define __i386 1
#define __i386__ 1
#define i386 1
pooka@watou:~$ cc -march=i486 -m32 -E -dM - < /dev/null | grep i.86
#define __tune_i486__ 1
#define __i386 1
#define __i486__ 1
#define __i386__ 1
#define __i486 1
#define i386 1
