vasilito ee1da17617 tests: add USB UHCI/OHCI/EHCI-autospawn/error-recovery QEMU proofs
Create the four USB validation scripts that local/docs/USB-VALIDATION-RUNBOOK.md
references but which did not exist on disk, closing the P8-B runtime-proof gap
for the legacy host controllers and the P8-C error-injection gap for xHCI:

- test-uhci-runtime-qemu.sh  (P1-B): -machine pc + piix3-usb-uhci, serial-log
  proof that uhcid binds the controller and detects the attached usb-kbd.
- test-ohci-runtime-qemu.sh  (P1-B): -machine pc + pci-ohci, serial-log proof
  that ohcid binds the controller and detects the attached usb-kbd.
- test-ehci-class-autospawn-qemu.sh (P1-A): -machine q35 + usb-ehci + usb-kbd,
  serial-log proof that ehcid enumerates the keyboard and usbhidd auto-spawns
  via the unified UsbHostController trait. The existing test-ehci-qemu.sh is a
  coarse usb-tablet smoke test and does NOT cover this path, so this is a full
  script rather than an alias.
- test-usb-error-recovery-qemu.sh (P8-C): hot-unplug usb-storage mid-transfer
  via the QEMU monitor device_del (chardev stdio mux, Ctrl-A c toggle — the
  same pattern as test-xhci-device-lifecycle-qemu.sh, since qemu-login-expect.py
  drives only serial and cannot reach the monitor). Proves graceful detach +
  usbscsid IO-error handling with no panic.

test-xhci-device-lifecycle-qemu.sh already existed and is unchanged.
test-usb-uas-qemu.sh is intentionally NOT created: UAS is in flight in a
separate workstream and its test belongs to that change.

Proof style and harness fidelity:
- UHCI/OHCI/EHCI proofs follow the test-xhci-irq-qemu.sh serial-log grep
  pattern (dual --check + interactive mode, ISO-preferred boot_args, 180s
  timeout, no panic fail-marker). No guest-side checker exists that validates
  legacy-controller enumeration specifically, so per the runbook's
  serial-log-evidence rule they grep driver log lines instead of inventing a
  guest binary.
- The error-recovery proof follows the test-xhci-device-lifecycle-qemu.sh
  expect/Tcl monitor-mux pattern and reuses the existing redbear-usb-storage-check
  guest binary (redbear-hwutils) to drive an active transfer — no new guest
  binary is invented.

All proof markers are sourced directly from the real driver trees:
  uhcid  main.rs:487/535/545  (UHCI USB 1.1 at / controller initialized / connect)
  ohcid  main.rs:305/341/348  (OHCI USB 1.1 at / controller initialized / connect)
  ehcid  main.rs:154/294/560  (EHCI USB 2.0 at / controller initialized / port device)
  usbhidd main.rs:221         (USB HID driver spawned with scheme)
  usbscsid main.rs:190/200/163/156 (READ/WRITE IO ERROR / scheme tick / event error)

No existing scripts, qemu-login-expect.py, config/*.toml, recipes, or the
runbook were modified. The runbook's script names and --check invocations
already matched exactly, so no runbook edits were required.

Validation: bash -n passes on all four scripts. shellcheck is not installed on
this host. NO QEMU runs were performed — the host is contended by another
workload that kills QEMU processes, so validation is syntax check + pattern
fidelity review only. Runtime pass/fail is unverified.
2026-07-20 10:04:56 +09:00

Red Bear OS

Red Bear OS

A microkernel operating system written in Rust — derived from Redox OS, built for bare metal.

MIT x86_64 Status


What is Red Bear OS?

Red Bear OS is a general-purpose, Unix-like operating system with a microkernel architecture, written entirely in Rust. It is a full fork of Redox OS (baseline 0.3.1), actively developed on branch 0.3.1 with hardware enablement, multiple filesystems, a native greeter and login system, and a KDE Plasma desktop path.

We aim to stay close to upstream Redox — diverging only where necessary to add missing functionality, fix bugs, or support new hardware. The build system itself is under constant active development alongside the OS.

It ships with several first-in-class Rust-native tools found nowhere else in the OS world:

  • cub — an AUR-inspired package manager with pacman-style CLI (-S/-Q/-R) and a ratatui TUI that converts Arch Linux PKGBUILDs into Red Bear recipes on the fly
  • tlc (Twilight Commander) — a pure-Rust reimplementation of Midnight Commander; dual-panel file manager, built-in editor and viewer, 8 color themes, 1204 unit tests, zero unsafe code
  • redbear-power — interactive ratatui TUI for live CPU frequency, governor, and thermal monitoring with on-the-fly P-state control

These are joined by dozens of redbear-* system utilities — redbear-netctl (network control), redbear-info (hardware diagnostics), redbear-acmd (admin CLI), redbear-mtr, redbear-nmap, redbear-btctl, and many more — all written in Rust, all built from source alongside the OS.

Goals:

  • AMD & Intel parity — equal-priority bare-metal support for both platforms
  • KDE Plasma desktop — Wayland-based desktop environment via the KWin compositor
  • Hardware GPU acceleration — AMD (amdgpu) and Intel GPU drivers via redox-drm
  • cub package ecosystem — AUR → recipe.toml pipeline giving access to thousands of packages
  • First-class subsystems — USB, WiFi, Bluetooth, ext4, FAT, GRUB, D-Bus (none optional)
  • Power management — CPU frequency scaling, thermal monitoring, RAPL, sleep states
  • Offline-first, reproducible builds — BLAKE3-verified source archives with content-hash caching

Our Git Server

Red Bear OS lives on a self-hosted Gitea instance at https://gitea.redbearos.org. This is the canonical home — no GitHub, GitLab, or Codeberg mirror is authoritative. There is exactly one repository: all component sources (kernel, relibc, drivers, system utilities) live here as submodule branches or tracked trees in local/sources/.

Field Value
Host https://gitea.redbearos.org
User vasilito
Web UI https://gitea.redbearos.org/vasilito
Main repo https://gitea.redbearos.org/vasilito/RedBear-OS

Authentication tokens are per-session credentials — never stored in the repo. See local/AGENTS.md § Our Git Server for the full operator runbook.


Quick Start

Prerequisites

Linux x86_64 host with Rust nightly, QEMU, nasm, and standard build tools. See the Redox Build Guide for full setup.

Build & Run

# Clone (read-only)
git clone https://gitea.redbearos.org/vasilito/RedBear-OS.git
cd RedBear-OS

# Authenticated clone — supply token via env var
git clone https://vasilito:${REDBEAR_GITEA_TOKEN}@gitea.redbearos.org/vasilito/RedBear-OS.git

# Canonical build entry point
./local/scripts/build-redbear.sh redbear-mini     # Text-only target
./local/scripts/build-redbear.sh redbear-full     # Desktop-capable target

# Boot in QEMU
make qemu

local/scripts/build-redbear.sh is the only supported build entry point. It handles .config parsing, prefix staleness detection, protected-recipe authorization, pre-cooking critical packages, and source fingerprint tracking. Direct make invocations bypass these gates. See AGENTS.md § Build Commands for details.

Config Targets

Target Type Description
redbear-full Desktop-capable GPU drivers + Wayland compositor + Qt 6.11.1 + KF6 6.27.0 + KWin + SDDM + greeter + D-Bus
redbear-mini Console Text-only recovery / install target with tlc, cub, and redbear-* utilities
redbear-grub Console Text-only with GRUB boot manager

Current Status

Red Bear OS boots to a login prompt in QEMU with working wired networking, D-Bus system bus, hardware detection daemons, and three filesystem backends (RedoxFS, ext4, FAT). The ISO builds successfully on branch 0.3.1. Graphics packages are frozen at latest upstream stable (Qt 6.11.1, KF6 6.27.0, Plasma 6.7.2, SDDM 0.21.0, Mesa 24.0.8).

Area Status
Boot (ACPI, x2APIC, SMP) Bare-metal proven — Ryzen Threadripper 128-thread verified
Userspace drivers (PCI, storage, net) Working in QEMU
Filesystems — RedoxFS, ext4, FAT Scheme daemons + mkfs/fsck tools
D-Bus system bus + services Working — login1, PolicyKit, UDisks, UPower
cub package manager 🟡 17-module Rust workspace; AUR → recipe pipeline; 70+ tests
tlc file manager 🟡 113 .rs files, 46k+ lines; 986 tests; 8 skins; VFS archives
IRQ / PCI / MSI-X / IOMMU 🟡 QEMU-proven; hardware validation open
POSIX gaps (relibc) 🟡 ~85% coverage; PATCHED-VIA-PATH-FORK — relibc changes are committed directly to local/sources/relibc/; local/patches/relibc/ holds reference and archived patches only
DRM/KMS display drivers 🟡 AMD + Intel + virtio-gpu compile; HW validation open
Mesa — llvmpipe + virgl 🟡 Builds (virtio_gpu_dri.so, 17.4 MB); virgl EGL runtime probe open
SDDM display manager + Greeter/Login 🟡 Wired in redbear-full; graphical login blocked by Qt6 Wayland crash
Qt 6.11.1 (Core, Gui, DBus, Wayland) 🟡 Builds successfully; Wayland null+8 crash blocks runtime
KF6 Frameworks — 40/40 🟡 All frameworks build; KWin cooks successfully
Wayland compositor 🟡 Bounded proof; blocked by Qt6 Wayland protocol crash
KWin 🟡 Builds successfully (redox-drm + Qt6 Wayland); runtime blocked by Qt6 Wayland crash in wl_proxy_add_listener
KDE Plasma 🔴 Runtime blocked by Qt6 Wayland null+8 crash — depends on KWin
WiFi (Intel iwlwifi) 🟡 VFIO/passthrough bounded runtime validation framework exists
USB / Bluetooth 🟡 xHCI mature in QEMU: 51-flag quirks, capability gating, 36-code error recovery, Linux hub enumeration state machine; storage BOT proven; hub runtime proof + UAS/HID expansion open; Bluetooth controller path planned

Where help is most wanted: Qt6 Wayland protocol crash — the #1 blocker for graphical desktop · AMD/Intel GPU hardware validation on bare metal · USB controller maturity · WiFi native control plane · cub AUR pipeline hardening · package maintainers for the growing recipe catalog · tlc VFS remote backends and archive support


How It Works

Red Bear OS uses a userspace driver model — all drivers run as unprivileged daemons communicating through the kernel's scheme-based IPC.

┌─────────────────────────────────────────────────────────────────┐
│                         KERNEL (microkernel)                     │
│          schemes: memory  ·  irq  ·  event  ·  pipe  ·  debug   │
└──────────────────────────┬──────────────────────────────────────┘
                           │
     ┌─────────────────────┼─────────────────────────┐
     ▼                     ▼                         ▼
┌──────────┐   ┌──────────────────┐   ┌──────────────────────┐
│  pcid    │   │  e1000d  xhcid   │   │  vesad  redox-drm    │
│ PCI enum │   │  Intel   USB 3.0 │   │  fbdev  GPU manager  │
└──────────┘   └──────────────────┘   └──────────────────────┘
┌──────────┐   ┌──────────────────┐   ┌──────────────────────┐
│  ext4d   │   │  ps2d   evdevd   │   │  thermald  cpufreqd  │
│  fatd    │   │  KB+mouse input  │   │  thermal   CPU freq  │
└──────────┘   └──────────────────┘   └──────────────────────┘
┌──────────┐   ┌──────────────────┐   ┌──────────────────────┐
│  iommu   │   │  acpid           │   │  dbus-daemon         │
│  DMA map │   │  power mgmt      │   │  system + session    │
└──────────┘   └──────────────────┘   └──────────────────────┘

The kernel provides minimal services: memory, interrupts, and IPC. Everything else — filesystems, networking, graphics, input, power management, D-Bus — runs in userspace. Hardware quirks are handled by a data-driven system in redox-driver-sys with compiled-in tables, TOML runtime configuration, and DMI matching.


Engineering Standards

Red Bear OS operates under strict discipline. Full policies: local/AGENTS.md.

Rule
Never delete to "fix" a build If a package breaks, fix the root cause. Never remove, ignore, or comment out a package, service, or config to make a build pass.
Zero stubs No fake headers, #ifdef no-ops, or "make it compile" shortcuts. Missing functionality must be implemented properly in the right component.
Single repository All component sources live here — no per-component repos. 9 submodule/<component> branches.
Local fork model Core components (kernel, relibc, base, bootloader, installer, redoxfs, userutils) are maintained as local forks in local/sources/ with immutability guarantees; syscall and libredox are wired as Cargo path dependencies via redbear-rt consumers, not via recipes/<comp>/recipe.toml path =.
Adapt to upstream Red Bear adapts to upstream API/ABI changes — never pins, downgrades, or holds back a dependency.
Free/libre only No proprietary, source-unavailable, or redistributability-restricted dependencies. MIT licensed.

Documentation


Contributing

Red Bear OS is a full fork of Redox OS. Upstream sources are frozen and archived; all custom work lives in local/ and survives every build operation.

local/
├── sources/    # Local forks of core components (kernel, relibc, base, bootloader, …)
├── recipes/    # Custom packages — drivers, GPU stack, system daemons, branding
├── patches/    # Durable changes to upstream source trees
│   └── (orphan-patch governance: every patch must correspond to work
│        present in the matching fork source tree. `verify-patch-content.sh`
│        enforces this on every build preflight. See
│        `local/docs/PATCH-PRESERVATION-AUDIT-2026-07-12.md` for the audit
│        and AGENTS.md § "Orphan-Patch Supersession Decision Tree" for the
│        decision flow when an orphan is detected.)
├── docs/       # Integration and planning documentation
└── scripts/    # Build, test, validation, and release tooling

We're Looking For

Role What you'd work on
Package maintainers Port and maintain AUR packages through cub's pipeline; write and test recipe.toml files for Red Bear OS; improve the PKGBUILD → recipe conversion
Driver developers AMD/Intel GPU drivers, USB controller maturity, WiFi native control plane, Bluetooth
Graphics stack engineers Qt6 Wayland crash fix (the #1 desktop blocker), Mesa virgl runtime, KWin Wayland compositor
Systems/Rust engineers Kernel syscalls, relibc POSIX gaps, filesystem daemons, D-Bus services, hardware quirks
TUI/app developers tlc feature completion, cub TUI polish, redbear-power enhancements, new redbear-* utilities

Contributions are welcome with or without AI assistance — we care about quality, not how the code was produced. Pick an area from the status table above, check the relevant plan doc, and dive in.


License

MIT — same as upstream Redox OS.

S
Description
RedBear Operating System, based on RedoxOS. Licenced under MIT license.
https://redbearos.org
Readme MIT 18 GiB
Languages
C 37.5%
C++ 37.2%
JavaScript 6.7%
QML 3.4%
HTML 3.2%
Other 11.4%