On Thursday, 02.04.2015 at 16:34, Joseph Myers wrote: > 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?
Yes. Currently we only have a NetBSD kernel and NetBSD libc, so my question about future Linux kernel and $LIBC support is hypothetical. > 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. A unikernel (which is what the rumprun toolchain builds) has no concept of running existing binaries. Your application, libraries, libc, rump kernel and platform support code are all linked into a single resulting image at build time. For Xen/baremetal, this image is an ELF kernel binary. For POSIX, it is a userspace ELF binary. See this recent post on rumpkernel-users which explains the internal architecture and layers: https://www.freelists.org/post/rumpkernel-users/internal-architecture-of-the-unified-rumprun-repository I'm not sure what you mean by "tuples do not distinguish the possible use of an emulation environment in which to run code". If by "emulation environment" you mean the target platform (xen, baremetal, posix, layer #1 in the architecture post), then we do need to distinguish between different platforms, if only to allow for installation of different toolchains side by side in eg. /usr/local/bin (goal "c" in my original email). > 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. So, for our case that would be *-rumprun-linux-gnu, describing a glibc port running on a Linux rump kernel. However, that loses the information about the target platform. I guess the "xen" "baremetal" and "posix" parts could go into the <vendor> component, giving *-rumprunxen-linux-gnu, etc. .. ? > 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. The last variant in the above paragraph is what we need to distinguish all possible tools/libc combinations. Why do you not recommend using the vendor component for anything significant? To me it seems the logical place to say "this is a rumprun toolchain", plus the result is easier to parse than putting "rumprun" AND "platform" AND "userspace" all in the last component. Martin
