Hi All,
I'm working on selecting the right architecture tuple for the Rumprun
toolchain[1] to use as a prefix for naming the cross tools and for passing
to application build systems (autoconf, CMake, ...). Rumprun is a software
stack built with Rump Kernels[2] which enables running existing POSIX
software without an operating system on various platforms (Xen, bare
metal/QEMU/KVM, POSIX userspace).
Our toolchain is somewhat special in that we don't currently build a cross
compiler from scratch, but instead generate wrappers and GCC spec files
which allow us to re-use an existing (cross-)compiler installed on the
build system.
My goals in settling on a correct naming scheme are the following:
a) choose a tuple that is as backwards-compatible as possible with
*existing, unmodified* build systems. I.e. any software that has
existing support for cross-compiling in its build system should "just
build".
b) ensure the naming scheme is extensible for future ISA, platform or
"userspace" combinations we've not yet thought of. See below for
discussion.
c) if possible, facilitate installing several toolchains for different
platforms side by side without needing to use separate directory
hierarchies. This is primarily for end-user convenience.
Based on discussion within our project I have come up with the following
two options:
1) Use the "Old form" [3] cpu-vendor-os:
'cpu' would be the target ISA (arm, i386, x86_64, ...).
'vendor' would be 'rumprun'.
'os' would be 'netbsd', as we currently provide a NetBSD-ish
"userspace".
Example: Toolchain would be installed as eg.
i386-rumprun-netbsd-{gcc,g++,...} and the autoconf tuple would be
i386-rumprun-netbsd.
2) Use the "New form" [3] cpu-vendor-kernel-os:
'cpu' would be the target ISA (arm, i386, x86_64, ...).
'vendor' would be 'rumprun'.
'kernel' would be the underlying platform that rumprun is running on,
i.e. 'xen', 'baremetal', 'posix', 'kvm', ...
'os' would be 'netbsd', as we currently provide a NetBSD-ish
"userspace".
Examples:
A Xen toolchain would be installed as eg.
i386-rumprun-xen-netbsd-{gcc,g++,...} and its autoconf tuple would be
i386-rumprun-xen-netbsd.
A POSIX toolchain would be installed as eg.
x86_64-rumprun-posix-netbsd-{gcc,g++,...} and its autoconf tuple would
be x86_64-rumprun-posix-netbsd.
A bare metal toolchain would be installed as eg.
arm-rumprun-baremetal-netbsd-{gcc,g++,...} and its autoconf tuple would
be arm-rumprun-baremetal-netbsd.
Option 1) satisfies only goal a), and I'm including it mostly for
completeness. Based on discussion so far it does not look like a good
long-term solution.
Option 2) satisfies goal b) (but see below regarding ABI), goal c) but not
goal a) due to requiring a manual update to the list of names understood by
config.sub and replacement of the config.sub script in all applications
[4].
So, with option 2), software will require manual patching on our side until
such future time as upstream maintainers get around to regenerating their
packages with an updated config.sub. This is unpleasant but I don't see any
way around it. Any ideas much appreciated.
Questions regarding goal b):
What to do regarding specifying the compiler ABI (eg. ARM-EABI) and
embedded subarchitecture (eg. hard/soft float, armv7, etc.)?
I've read through past discussion regarding choice of tuples for Debian
multiarch [5] and this seems to suggest extending either the 'cpu' or 'os'
field of the architecture tuple, so we'd end up with combinations like:
armeb-rumprun-baremetal-netbsdeabihf
mipsel-rumprun-baremetal-netbsdsf
Regarding future possibilities, the Rump Kernel/anykernel concept is
applicable to other operating system kernels, not just NetBSD. So, say
someone does the work to use the Linux kernel as an anykernel, we could
then provide a Linux "userspace". This would give us the following example
future combinations:
x86_64-rumprun-xen-linux (Rumprun, on x86_64 ISA, running a Linux Rump
Kernel on Xen)
aarch64-rumprun-baremetal-linux (Rumprun, on AARCH64 ISA, running a Linux
Rump Kernel on bare metal)
Is this the right way to go, now and in the future?
Any advice will be much appreciated, I'd like to get this right now since
we'll be stuck with it for the forseeable future.
Thanks,
Martin
[1] http://repo.rumpkernel.org/rumprun
[2] http://rumpkernel.org/
[3] As documented in the comments at the start of 'config.sub':
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
[4] Example using one of the architecture tuples above with an existing
application that builds using autoconf:
./configure --host=x86_64-rumprun-xen-netbsd --build=x86_64-linux-gnu
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `x86_64-rumprun-xen-netbsd':
machine `x86_64-rumprun-xen' not recognized
configure: error: /bin/bash build-aux/config.sub x86_64-rumprun-xen-netbsd
failed
[5] https://wiki.debian.org/Multiarch/Tuples
