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. The differences are only important when baking the final unikernel image at which point we need to know the board since we need to link in the right set of components, startup code, decide between bmk or xen and use the correct linker script. > >Currently we have no way to link in drivers and/or board-specific > >initialisation code except at the final call to "ld". Therefore, unless > >inspiration hits and we figure out the "pseudo-linking" arrangement I don't > >think we have any other option than to make the board name part of the > >toolchain name. I'm not sure how that will fit in with selecting "optional" > >drivers / removing non-default ones as I write above. > > 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: 1) two sets of compiler specs, "ferment" and "bake". 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. 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 :) >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? > Another option is to decide that baking and toolchain naming are > independent problems, and even if we implement > pseudo-linking/rumpbake/whatever in the future, we can still drag > the board name in the toolchain tuple without, um, drag. I'm > undecided if they are independent. I think I answered that above. > >users, I guess that would be i686. > > 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. Martin
