QSOE 0.2 release

The second QSOE release, v0.2, is out. As before it is a single numbered drop of both kernel variants, the boot loader, the shared userspace and libc:

• QSOE/N v0.26, with the custom "Skimmer" kernel.
• QSOE/L v0.22, which works together with seL4 version 16.0.0.
• mr-bml v0.9, the GRUB-derived boot loader.
• quser v0.14, the shared userspace: the shell, the drivers, the servers and the utilities.
• libc v0.15.

0.1 was a system you watched over a serial cable. 0.2 is one you can sit at. devc-hficon paints a text console on a graphics controller that the firmware hands over — a GK208 on the Unmatched, the SoC display block on the K3 — and devu-xhci enumerates a USB keyboard that types into it, so a login: prompt appears on the monitor and answers. The shell gained pipelines (without fork(), which QSOE deliberately does not have), command substitution, job control, and a Ctrl-C that reaches the command and then the shell; an orthodox two-panel file manager and a full-screen editor are built into it. And fs-tmpfs is the first place in QSOE where a file can be created at all.

The feature this release is named for is QSP, transparent distributed networking. open("/net/node2/dev/ser1") opens the serial port on the other machine, and the resource manager over there is never told that anything unusual happened — it sees an ordinary local client. That is what makes every driver already written work across the net unmodified. The relay deliberately does not decode: exactly two message types are looked at, the open that names the resource and the close that releases it, and everything else crosses as bytes, so an application's own private protocol passes through unchanged.

QSOE/N coming up on the SpacemiT K3 Pico-ITX. Five stations are already on the roster — /net/k3 is this machine, and the Unmatched, the VisionFive 2, a QEMU instance and the build host are each one open() away.

QSOE/N gained a second silicon target, the SpacemiT K3 Pico-ITX — sixteen harts, pure AIA with no PLIC anywhere on the SoC, and DRAM starting at 4 GiB. Ethernet arrived with it: devn-gem for the Unmatched, devn-dwmac for the K3, and devn-virtio for QEMU, all three behind one physically contiguous, uncached descriptor ring published to the client. A frame is written once and read in place, instead of being carried through a message round trip that could not hold it whole.

Below the seam, a server can now find out who is talking to it. Every client of every server used to be root — not as a policy, but as a constant in the framework's open path. Both kernels now carry the sender's identity, each by the means it allows: QSOE/N reads the credentials at send time, so they are current, and QSOE/L stamps them into the connection badge at ConnectAttach, which is the one moment taskman can. The answer is acted on: fs-qrv checks the permission triads, so an ordinary user reading /etc/shadow is refused. One consequence is worth stating on its own — su needs no setuid bit here, and QSOE has none. taskman owns the credential table and the password database, so su is an ordinary unprivileged program: it hands taskman a name and a password, and taskman verifies them and changes the caller's identity itself. There is no separation to bridge, and therefore no privileged intermediary to write.

Two structural changes are worth naming. ioctl() is retired: device control is devcontrol(), which carries the subsystem, the direction of travel and the command as three unsigned values instead of packing all three into one signed integer that no one verifies. And taskman is the dynamic loader on both kernels — it loads the program, libc.so and every library named by DT_NEEDED, applies the relocations and jumps to the entry point. The separate run-time loader turned out never to have run at all, and has been deleted rather than maintained.

The manuals moved with the code, as they must: six of them now, including a new C Library Reference covering what libc gained since 0.1.

The source is on GitLab under Apache-2.0, at gitlab.com/qsoe. Binaries and documentation are hosted on GitHub, and download and installation instructions live on the project website, qsoe.net — where a self-booting QEMU disk image is the fastest way to see it run. Next is 0.3: writes on the on-disk filesystem, so that a QSOE machine can eventually build QSOE.