On Wednesday, 06.05.2015 at 11:23, Antti Kantee wrote:
> There were two ongoing discussions:
>
> 1) should the tuple contain the platform at all
> 2) can we think of a better platform name for "baremetal"
>
> If the answer to "1" is "yes", then we definitely shouldn't leave it
> empty in any case.
>
> The argument in favor of "yes" for "1" was that users can look at
> the tuple alone and decide where that particular toolchain can be
> used.
>
> The argument in favor of "no" for "1" was that since the toolchain
> also implies everything about the platform (including how to boot
> it, where devices are located, etc), you need some sort of
> "platform+board" construct there for the rational for "yes" to
> apply. It's probably not sensible to fully enumerate every option
> in that space in the tuple. Therefore, it's better to supply no
> information than misleading information.
As we can see from the baremetal case, the toolchain does *not* imply
everything about the platform. Therefore, that is an argument in favour of
"no".
Further, from the point of view of the compiler and most(***) userspace
software the baremetal, xen and posix toolchains are essentially
equivalent. The code generated is the same for all three variants, as is
the ABI since we don't have syscalls.
Therefore, that is another argument in favour of "no" for putting the
platform+board construct in either the toolchain name or autoconf tuple.
So, a thought experiment: Can we unify the different toolchains altogether?
In order to do that, we need the extra information about the
platform+board to come from somewhere. Inventing nonstandard compiler flags
is not a good solution.
The only logical channel remaining would appear to be an environment
variable.
So, how about this:
1) We unify the toolchain wrappers, dropping the platform from the names
entirely. Therefore, the tools are named simply
<cpu>-rumprun-netbsd*-{gcc,g++,...}. The autoconf tuple will be
<cpu>-rumprun-netbsd*. (*) Can be "elf", etc. to mirror native NetBSD
usage.
2) The user *must* set an environment variable, (say) RUMPRUN_TARGET to
specify (say) "xen", "qemu", "rpi", ... We will need to think about that
namespace.
3) If the environment variable is *not* set, the toolchain wrappers will
complain loudly and fail.
(***) Some, (currently) rare, software may wish to take advantage of
special interfaces specific to a particular platform hypervisor. e.g. The
Xen folks work on getting qemu running as a rump kernel. The question
remains, do we need to provide anything special (#defines, autoconf string)
for such software or not?
If the answer to the above is "no" then such software must be manually
told about the target platform at build time and the proposal for a single,
unified, toolchain as desribed above holds.
If the answer to the above is "yes", then we will still need to keep the
separate naming scheme, at least for Xen.
Thoughts?
Martin
