On 25/05/15 13:22, Martin Lucina wrote:
Current status: we have no way of specifying what rump kernel
components get linked, apart from editing the Makefile that
generates the toolchain.
I'd forgotten about that. This is also important for scenarios where the
user does not need all of the default set of drivers linked in (embedded
devices, rumprun+Mirage unikernels using the Mirage TCP stack, future Xen
unikernels using vchan only, etc.).
'zactly. We might as well build an OS if we're not taking advantage of
the component-oriented nature of rump kernels ;)
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)
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.
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.
3) What arch are we going to use for x86? i686?
Why wouldn't we use the right one, i.e. if you're compiling with
-march=i486 it's i486, with -march=pentiumpro it's i686 etc. ?
Sure. Though we'll still want to provide some default for the majority of
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?
