This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Selecting an architecture tuple for the Rumprun toolchain

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]