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 jos...@codesourcery.com
