Joseph Myers writes ("Re: Selecting an architecture tuple for the Rumprun
toolchain"):
> If you would use a different glibc port, but providing access to
> Linux-specific interfaces, then the tuple would be
> <arch>-<vendor>-<kernel>-gnu, much like *-*-kfreebsd-gnu describes a glibc
> port running on the FreeBSD kernel.
As Martin says, rumprun is not using glibc (and is not expected to any
time soon). So it should not have -gnu.
The problem we are having here is that rumprun doesn't fit in the nice
tidy scheme of these arch tuples. I think the right thing to do is to
consider how these tuples are usually used, to try to understand how
best to express reality within the existing framework.
There are three contexts for the arch tuple:
1. Toolstack name prefixes (and header and library path prefixes).
For this purpose it is necessary to have _different_ names for
different rumprun targets. This is necessary because object
files, libraries, etc. etc., are compiled differently for
different rumprun execution environments.
So we need a string in the tuple like `posix' or `xen' which
indicates the underlying target.
2. Selecting the correct portability options in existing software
For this purpose we need primarily to specify that this is netbsd.
This is because the libc is netbsd, and the system calls, insofar
as they are useable, are generally very like netbsd. This should
appear in the tuple in the place where the libc and/or kernel are
normally reported.
We also need to specify the cpu architecture.
3. Selecting rumpkernel-specific options in rumpkernel-aware software
Some (rare) software wants to do something special in a rumpkernel
environment. So we need to specify `rumprun' or `rumpkernel' or
something, somewhere.
Existing netbsd seems to use
<cpu>-unknown-netbsdSOMETHING
These considerations lead me to suggest:
<cpu>-rumprun{posix,xen,baremetal}-netbsd
We need to wedge the target environemnt and rumprun into the same part
of the tuple because we need existing consumers of the tuple to ignore
it thinking it's an irrelevant `vendor'.
Note that the target environment is nothing like the `kernel'.
rumprun applications do not normally get access to the target
environment. It does not provide `system calls'.
Indeed rumprun applications are in the usual case deliberately kept
oblivious of the target environment. So in that sense it does
resemble the `emulation environment' case, and Joseph is right to say
that the application doesn't and shouldn't (normally) need to know.
However, the _user_ does need to know because (as I say) the ABIs,
object formats, header files, etc. etc. etc., are different. So since
the tuple is used not only to tell the application about the
environment but also by the user to specify how to build, it must
contain this information.
Thanks,
Ian.
