This is the mail archive of the
mailing list for the GCC project.
Re: Selecting an architecture tuple for the Rumprun toolchain
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Lucina <martin at lucina dot net>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Thu, 2 Apr 2015 16:34:44 +0000
- Subject: Re: Selecting an architecture tuple for the Rumprun toolchain
- Authentication-results: sourceware.org; auth=none
- References: <20150330142356 dot GE7411 at nodbug dot moloch dot sk>
On Mon, 30 Mar 2015, Martin Lucina wrote:
> 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?
The concept of a Linux userspace does not make sense; Linux is a kernel.
By Linux userspace, do you mean that the C library used provides
interfaces to Linux-specific syscalls such as inotify and signalfd, and
the headers provide Linux-specific ioctls, and those syscalls and ioctls
work at runtime, and that the headers include the uapi headers exported by
the Linux kernel?
If existing binaries built for the existing Linux kernel with glibc
userspace (existing glibc ports) would run in your environment, then the
existing *-linux-gnu triplets should be used; tuples do not distinguish
the possible use of an emulation environment in which to run code.
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.
If you would use a different glibc port, would it be meaningful to do so
both for Linux (however Linux is involved in your system) and for NetBSD?
If so, it seems you have something like (but different from)
*-*-linux-gnu, and something like (but different from) *-*-knetbsd-gnu -
if both kernels affect the glibc port in some way, the kernel component of
the triplet might need to include both kernel names, or else the OS
component might need to contain one of them. (I don't recommend treating
the vendor component as semantically significant.) Thus, you might have
arm-*-linux-gnueabirumprun, or (if multiple rumprun variants each need
their own tools / libc) arm-*-linux-gnueabirumprunxen.
If you would use a different glibc port, but that port does not provide
any Linux-specific interfaces and is independent of the underlying kernel
(if rumprun binaries are portable to all kernels that might be used), then
<arch>-<vendor>-rumprun-gnu would be appropriate.
If you would use some other libc, then the -gnu component would not appear
in the tuple at all (much like *-*-linux-uclibc for tools configured to
use the Linux kernel with uClibc-based userspace). Similar reasoning to
the above can be applied to use of a non-GNU userspace providing access to
Linux-specific kernel/userspace interfaces (syscalls, ioctls etc.).
Joseph S. Myers