Thanks Martin, I'm extremely pleased about how things worked out. I
think you are borderline understating the significance of this
development, so I will try to hype it a bit more ;)
On 28/05/15 16:49, Martin Lucina wrote:
The user-visible change is that `rumprun-*-cc' will no longer produce a
unikernel image, but instead produce an intermediate file that must be
"bakend" into the final unikernel image with `rumpbake'. "Hello, world"
example:
"bakend"? Are we speaking pseudo-swedish now? ;)
$ rumprun-bmk-cc -o hello hello.c
(produces an intermediate "hello")
Notably, it not only produces a binary, but also guarantees that baking
hello will not fail due to missing libraries or similar. This detail is
important, since it allows for a familiar unikernel building experience
for people with a background in "make+vi". (of course, also the
previous build model flagged errors, but the key is that the new model
does not cause regressions there)
$ rumpbake -T hw_generic -o hello.bin hello
(produces the final unikernel as "hello.bin", targeted for the "hw_generic"
configuration)
Equally notably, we can in the future (after figuring out a bunch of
other things) specify hello1 & hello2 to be baked into the same image.
Even so, both hello{1,2} can still be compiled with "make" as usual, so
no special build system hackery is required. Again, this detail makes
for a good user experience.
I would also like to note that I already added my own hw_virtio
component configuration, and it was supertrivial to do. Users can very
easily bake exactly the rump kernel component configuration that they
want (well, with some limitations. for example, I don't think a rumprun
unikernel would work without librumpvfs, but we'll call that a
limitation of reality).
$ rumprun qemu ./hello.bin
(boots the unikernel)
it's even better with "rumprun qemu -i ./hello.bin" ;)
2) Toolchain renaming
With `rumpbake', we are hopefully now in a position to unify and rename the
app-tools toolchain, using the following scheme:
<CPU>-rumprun-netbsd{elf}
Examples:
i686-rumprun-netbsdelf (32-bit Intel compiler targeted for i686)
x86_64-rumprun-netbsd (64-bit Intel compiler targeted for x86_64)
arm<SUBARCH>-rumprun-netbsd (32-bit ARM compiler targeted for <SUBARCH>)
This means we will NOT need to put the `board' or `platform' in either the
toolchain name or autoconf tuple. Applications can be built once using the
toolchain appropriate for the target CPU.
If anyone has any last-minute input on the above scheme, please speak up
now!
Looks good to me, but maybe wait for a day or so in case anyone else has
comments. As much as I want to get the toolchain name stamped down, I
don't want to see it changed ever again afterwards ;)
Then we can slowly start ironing down the usages & syntaxes of
rump{bake,run}.
- antti
