vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: consolidate — CONSOLE-TO-KDE v4.0 supersedes all individual plans

Browse Source 
CONSOLE-TO-KDE-DESKTOP-PLAN.md rewritten as v4.0 comprehensive plan:
- Single authority for all desktop-path decisions
- Full layer reassessment: DRM→Mesa→Wayland→KDE (6 layers)
- Honest blocker map with effort estimates
- Credential syscalls marked RESOLVED
- Software-rendered path: 8-14 weeks
- Hardware-accelerated path: 20-34 weeks

Stale docs deleted (13, consolidated):
- COMPREHENSIVE-OS-ASSESSMENT, DESKTOP-STACK-CURRENT-STATUS
- AMD-FIRST-INTEGRATION, HARDWARE-3D-ASSESSMENT, DMA-BUF-IMPROVEMENT, INPUT-SCHEME-ENHANCEMENT
- BOOT-PROCESS-ASSESSMENT, LINUX-BORROWING-RUST
- QT6-PORT-STATUS, REDBEAR-INFO-RUNTIME-REPORT
- RELIBC-COMPREHENSIVE, RELIBC-COMPLETENESS, RELIBC-IMPLEMENTATION

docs/README.md: updated status matrix, removed dead references
This commit is contained in:
Vasilito
2026-04-30 23:59:36 +01:00
parent 7c7399e0a6
commit a2d3c9181e
20 changed files with 516 additions and 5041 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/README.md
+20 -19
View File
@@ -38,12 +38,13 @@ current/canonical versus historical/reference split obvious.
| Document set | Role |
|---|---|
| `README.md`, `AGENTS.md`, `docs/README.md`, `docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md` | canonical repository-level policy and current execution model |
| `local/docs/*IMPLEMENTATION-PLAN*.md`, `local/docs/*STATUS*.md`, `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`, `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` | canonical current Red Bear subsystem plans and status |
| `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | **canonical comprehensive implementation plan** — supersedes all individual subsystem docs |
| `local/docs/*IMPLEMENTATION-PLAN*.md`, `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` | subsystem plans for deep-dive detail only; authority chain → console-to-KDE plan |
| `docs/01-REDOX-ARCHITECTURE.md` | architecture reference |
| `docs/04-LINUX-DRIVER-COMPAT.md`, `docs/05-KDE-PLASMA-ON-REDOX.md` | valuable but partly historical roadmap/design material |
When a current-state local document conflicts with an older historical public roadmap, prefer the
current local subsystem plan.
console-to-KDE plan.
## Documents
@@ -57,23 +58,23 @@ current local subsystem plan.
## Related Red Bear-local current-state plans
- `../local/docs/USB-IMPLEMENTATION-PLAN.md` — current USB completeness and rollout plan
- `../local/docs/WIFI-IMPLEMENTATION-PLAN.md` — current Wi-Fi architecture and rollout plan
- `../local/recipes/system/redbear-netctl-console/source/` — Redox-native ncurses terminal client for the bounded Wi-Fi profile flow
- `../local/docs/SCRIPT-BEHAVIOR-MATRIX.md` — guarantees and non-guarantees for the main Wi-Fi and Bluetooth validation helpers plus core repo scripts
- `../local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md` — current Bluetooth architecture and rollout plan
- `../local/docs/ACPI-IMPROVEMENT-PLAN.md` — current ACPI ownership, robustness, and validation plan
- `../local/docs/ACPI-IMPROVEMENT-PLAN.md` — current ACPI ownership, robustness, and validation plan
- `../local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` — canonical current plan for PCI/IRQ quality, low-level controller robustness, MSI/MSI-X follow-up, and controller runtime-proof sequencing
- `../local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` — current DRM-focused execution plan beneath the canonical desktop path, with equal Intel/AMD evidence bars
- `../local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` — canonical Wayland subsystem plan beneath the desktop path
- `../local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md` — canonical relibc quality/completeness/robustness assessment and improvement plan
- `../local/docs/RELIBC-IMPLEMENTATION-PLAN.md` — implementation roadmap for closing relibc POSIX gaps
- `../local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md` — IPC-focused companion plan for the active relibc compatibility surface
- `../local/docs/GREETER-LOGIN-IMPLEMENTATION-PLAN.md` — canonical greeter/login plan for the Red Bear-native login boundary on `redbear-full`
- PCI vendor/device names in Red Bear runtime tools now come from the shipped `pciids` database; PCI quirk policy still lives in `../local/docs/QUIRKS-SYSTEM.md`
- `../local/docs/AMD-FIRST-INTEGRATION.md` — AMD-focused technical roadmap and hardware detail only, not the canonical desktop plan
- `../local/docs/DESKTOP-STACK-CURRENT-STATUS.md` — canonical current build/runtime truth summary for the desktop stack
**Consolidation (2026-04-30)**: 13 standalone assessment docs deleted. All current state is now in
`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v4.0). Individual subsystem plans remain for detail:
- `../local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` — **CANONICAL** comprehensive plan: kernel→DRM→Mesa→Wayland→KDE path
- `../local/docs/KERNEL-IPC-CREDENTIAL-PLAN.md` — kernel credential syscalls + IPC (implemented)
- `../local/docs/USB-IMPLEMENTATION-PLAN.md` — USB completeness and rollout
- `../local/docs/WIFI-IMPLEMENTATION-PLAN.md` — Wi-Fi architecture and rollout
- `../local/docs/BLUETOOTH-IMPLEMENTATION-PLAN.md` — Bluetooth architecture and rollout
- `../local/docs/ACPI-IMPROVEMENT-PLAN.md` — ACPI ownership, robustness, validation
- `../local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` — PCI/IRQ quality, MSI/MSI-X
- `../local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` — DRM-focused execution (subsystem detail)
- `../local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` — Wayland compositor (subsystem detail)
- `../local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md` — relibc IPC surface
- `../local/docs/GREETER-LOGIN-IMPLEMENTATION-PLAN.md` — greeter/login design
- `../local/docs/DBUS-INTEGRATION-PLAN.md` — D-Bus architecture
- `../local/docs/SCRIPT-BEHAVIOR-MATRIX.md` — script guarantees and non-guarantees
- `../local/docs/QUIRKS-SYSTEM.md` — hardware quirks infrastructure
These local Red Bear plans should be treated as first-class subsystem references for desktop/session,
USB, Wi-Fi, Bluetooth, and low-level controller work. They carry blocker detail that the public docs
local/docs/AMD-FIRST-INTEGRATION.md
-484
View File
@@ -1,484 +0,0 @@
# AMD-SPECIFIC REDOX OS — GPU/DRIVER INTEGRATION REFERENCE
> **Status note (2026-04-16):** This document remains the detailed AMD-focused hardware roadmap.
> It is no longer the canonical desktop path plan — see
> `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` for that role. This file is now scoped to AMD-specific
> hardware integration detail only.
>
> The P0–P6 section headings below refer to the historical hardware-enablement sequence, not the
> v2.0 desktop plan phases (Phase 1–5). Where numbering conflicts with the v2.0 plan, the v2.0 plan
> takes precedence.
>
> Red Bear OS now treats AMD and Intel machines as equal-priority targets. Read this file as the
> deeper AMD-specific technical plan, not as a platform-priority statement.
>
> **Planning authority note (2026-04-18):** for current GPU/DRM execution order and acceptance
> criteria, use `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`. This file remains a detailed AMD
> technical/reference document, not the canonical GPU plan.
**Target**: AMD64 bare metal machine with AMD GPU (RDNA2/RDNA3), within an overall Red Bear OS
hardware policy that treats AMD and Intel machines as equal-priority targets.
**Date**: 2026-04-11
## CRITICAL FINDINGS
### amdgpu is 18x larger than Intel i915
| Driver | Lines of Code | Complexity |
|--------|--------------|------------|
| amdgpu (AMD) | **6,048,151** | Largest driver in Linux kernel |
| i915 (Intel) | ~341,000 | Well-documented, simpler |
| nouveau (NVIDIA) | ~400,000 | Community driver |
**Implication**: The AMD path is HARDER but still important. For AMD-class Linux GPU and related
device enablement, we MUST use the LinuxKPI compatibility approach — a clean Rust rewrite would
take 5+ years.
### AMD Bare Metal Status on Redox
| Component | Status | Detail |
|-----------|--------|--------|
| UEFI boot | ✅ Works | x86_64 UEFI bootloader functional |
| AMD CPUs | ✅ Works | AMD 32/64-bit supported, Ryzen Threadripper verified |
| ACPI | ✅ Boot-baseline complete | RSDP/SDT checksums, MADT types 0x4/0x5/0x9/0xA, LVT NMI, FADT shutdown/reboot, explicit `RSDP_ADDR` forwarding into `acpid`, x86 BIOS-search AML fallback, and bounded AML-backed power enumeration exist; historical bring-up goal met, but the explicit AML bootstrap producer contract, startup hardening, sleep-state scope, and validation depth still remain open — see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for the forward plan |
| x2APIC | ✅ Works | Auto-detected via CPUID, APIC/SMP functional |
| HPET | ✅ Works | Timer initialized from ACPI |
| IOMMU | 🚧 In progress | `iommu` daemon now builds, auto-discovers common IVRS table paths, reaches unit detection plus `scheme:iommu` registration in the QEMU/AMD-IOMMU validation path, and now has a guest-driven first-use self-test that initializes both discovered units and drains events successfully in QEMU; real hardware validation is still missing |
| AMD GPU | 🚧 In progress | MMIO mapped, bounded Red Bear display glue path builds, MSI-X wired; imported Linux AMD DC/TTM/core remain builds and included in redbear-full (2026-04-29); no hardware validation yet |
| Wi-Fi/BT | 🚧 In progress | Repo now carries bounded wireless scaffolding: one experimental in-tree Bluetooth slice exists, and a bounded Intel Wi-Fi scaffold exists elsewhere, but validated wireless connectivity support is still incomplete |
| USB | ⚠️ Variable | Some USB controllers work, others don't |
### Known AMD-Specific Issues
1. **ASUS PRIME B350M-E**: Partial PS/2 keyboard, mouse broken
2. **Zen3+ page alignment**: Potential memory corruption with 16k-aligned pages
3. **I2C on AMD platforms**: Touchpad may fail
---
## PHASE 0: BARE METAL BOOT ON AMD (4-6 weeks)
Before any GPU or desktop work, Redox must boot reliably on modern AMD hardware.
### P0-1: Fix ACPI for AMD (historical milestone)
**Historical problem**: Framework AMD Ryzen 7040 crashed because the early ACPI boot baseline was
incomplete.
**Current status**: This historical P0 boot-baseline gap is materially complete for the AMD bring-up
goal, but it should not be read as release-grade ACPI completeness. The remaining ACPI work is no
longer "make AMD machines boot at all"; it is now ownership cleanup, robustness, sleep-state scope,
consumer integration, and validation depth as tracked in `local/docs/ACPI-IMPROVEMENT-PLAN.md`.
**What was done**:
- Implement the missing ACPI boot-baseline support needed for modern AMD bring-up
- Validate the repaired path on the bounded AMD bare-metal targets available during the P0 pass
- Preserve the resulting work in the kernel and `acpid` patch carriers
**Where**:
- Kernel: `recipes/core/kernel/source/src/acpi/`
- acpid: `recipes/core/base/source/drivers/acpid/`
- Patches: `local/patches/kernel/`
### P0-2: AMD-Specific Boot Hardening
**What to do**:
- Fix CPUID validation (FIXME in cpuid.rs)
- Fix Zen3+ page alignment issue (16k-aligned page smashing)
- Ensure trampoline page permissions are correct
- Validate memory map parsing on AMD systems with >4GB
**Where**: `recipes/core/kernel/source/src/arch/x86_64/`
### P0-3: Hardware Testing Matrix
**Required test hardware**:
- AMD Ryzen desktop (B550/X570 motherboard)
- AMD Ryzen laptop (Framework 16 or similar)
- AMD APU system (Ryzen 5xxxG series)
**Test procedure**: Write to `local/scripts/test-baremetal.sh`
---
## PHASE 1: DRIVER INFRASTRUCTURE (8-12 weeks)
### P1-1: redox-driver-sys Crate
**Purpose**: Safe Rust wrappers around Redox scheme-based hardware access.
```
local/recipes/drivers/redox-driver-sys/
├── Cargo.toml
├── src/
│ ├── lib.rs # Re-exports
│ ├── memory.rs # Physical memory mapping (scheme:memory)
│ ├── irq.rs # Interrupt handling (scheme:irq)
│ ├── pci.rs # PCI device access (scheme:pci / pcid)
│ ├── io.rs # Port I/O (iopl syscall)
│ └── dma.rs # DMA buffer management
```
**API design**: See `docs/04-LINUX-DRIVER-COMPAT.md` §Crate 1.
### P1-2: Firmware Loading Infrastructure
**Purpose**: Load AMD GPU firmware blobs from filesystem.
```
local/recipes/system/firmware-loader/
├── Cargo.toml
├── src/
│ ├── main.rs # Daemon: registers scheme:firmware
│ ├── scheme.rs # "firmware" scheme handler
│ └── blob.rs # Firmware blob management
```
**Firmware blobs needed for amdgpu** (from linux-firmware):
| Block | Purpose | File Pattern |
|-------|---------|-------------|
| PSP | Security processor | `psp_*_sos.bin`, `psp_*_ta.bin` |
| GC | Graphics/shader engine | `gc_*_me.bin`, `gc_*_pfp.bin`, `gc_*_ce.bin` |
| SDMA | DMA engine | `sdma_*_bin.bin` |
| VCN | Video encode/decode | `vcn_*_bin.bin` |
| SMC | Power management | `smu_*_bin.bin` |
| DMCUB | Display controller | `dcn_*_dmcub.bin` |
**Storage**: staged into `/lib/firmware/amdgpu/` for runtime loading. The current local helper
script still fetches AMD blobs from linux-firmware, but the runtime path should now be read as
`/lib/firmware/amdgpu/`, not `/usr/firmware/amdgpu/`.
### P1-3: linux-kpi Compatibility Headers
**Purpose**: C headers translating Linux kernel APIs → redox-driver-sys Rust calls.
```
local/recipes/drivers/linux-kpi/
├── Cargo.toml
├── src/
│ ├── lib.rs
│ ├── c_headers/linux/
│ │ ├── slab.h # → malloc/kfree
│ │ ├── mutex.h # → pthread mutex
│ │ ├── spinlock.h # → atomic lock
│ │ ├── pci.h # → redox-driver-sys::pci
│ │ ├── io.h # → port I/O
│ │ ├── irq.h # → redox-driver-sys::irq
│ │ ├── device.h # → struct device wrapper
│ │ ├── workqueue.h # → thread pool
│ │ ├── dma-mapping.h # → bus DMA
│ │ └── firmware.h # → firmware_loader scheme
│ ├── c_headers/drm/
│ │ ├── drm.h
│ │ ├── drm_crtc.h
│ │ ├── drm_gem.h
│ │ └── drm_ioctl.h
│ └── rust_impl/
│ ├── memory.rs # kmalloc, kzalloc, kfree
│ ├── sync.rs # mutex, spinlock, completion
│ ├── pci.rs # pci_register_driver
│ ├── firmware.rs # request_firmware
│ └── drm_shim.rs # DRM core → scheme:drm
```
---
## PHASE 2: AMD GPU DISPLAY OUTPUT (12-16 weeks)
### P2-1: redox-drm Daemon
**Purpose**: DRM scheme daemon — registers `scheme:drm/card0`.
```
local/recipes/gpu/redox-drm/
├── Cargo.toml
├── src/
│ ├── main.rs # Daemon entry, PCI enumeration for AMD GPUs
│ ├── scheme.rs # Registers "drm" scheme
│ ├── kms/ # KMS core
│ │ ├── crtc.rs # CRTC state machine
│ │ ├── connector.rs # Hotplug, EDID
│ │ ├── encoder.rs # Encoder management
│ │ └── plane.rs # Primary/cursor planes
│ ├── gem.rs # GEM buffer objects
│ └── drivers/
│ ├── mod.rs # trait GpuDriver
│ └── amd/
│ ├── mod.rs # AMD driver entry
│ ├── display.rs # Display Core (DC) port
│ ├── gtt.rs # Graphics Translation Table
│ └── ring.rs # Command ring buffer
```
### P2-2: AMD Display Core Port (Mode A — C port)
**The critical decision**: amdgpu's display code (AMD DC) is ~1.5M lines. We port
ONLY the display/modesetting portion first, using linux-kpi headers.
**Approach**:
1. Extract `drivers/gpu/drm/amd/display/` from Linux kernel
2. Compile against linux-kpi headers with `-D__redox__`
3. Run as userspace daemon under redox-drm
4. Start with basic modesetting (no acceleration)
**Estimated patches**: ~3000-5000 lines of `#ifdef __redox__`
### P2-3: Firmware Loading for AMD
**Sequence on boot**:
```
1. pcid detects AMD GPU (vendor 0x1002)
2. pcid-spawner launches redox-drm with PCI device info
3. redox-drm maps MMIO registers via scheme:memory
4. redox-drm loads PSP firmware via scheme:firmware
5. PSP firmware loads GC, SDMA, SMC, DMCUB sub-firmwares
6. AMD DC initializes display pipeline
7. scheme:drm/card0 registered
8. modetest -M amd shows display modes
```
### Verification (Phase 2 complete when):
- `scheme:drm/card0` exists
- `modetest -M amd` shows connector info and modes
- `modetest -M amd -s 0:1920x1080` sets mode and shows test pattern
- Works on real AMD hardware (not just QEMU)
---
## P1/P2 IMPLEMENTATION STATUS (2026-04-12)
### P1: Driver Infrastructure — COMPLETE (compiles)
| Component | Status | Files |
|-----------|--------|-------|
| redox-driver-sys | ✅ | `local/recipes/drivers/redox-driver-sys/source/` — PCI, IRQ (MSI-X), MMIO, DMA |
| linux-kpi | ✅ | `local/recipes/drivers/linux-kpi/source/` — C compat headers + Rust shims |
| firmware-loader | ✅ | `local/recipes/system/firmware-loader/source/` — scheme:firmware daemon |
| pcid /config endpoint | ✅ | `local/patches/base/P0-pcid-config-endpoint.patch` — raw PCI config space via scheme:pci |
| MSI-X interrupt support | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/interrupt.rs` — shared MSI-X/MSI/legacy abstraction with quirk-aware fallback |
| Intel pcid-spawner config | ✅ | `local/config/pcid.d/intel_gpu.toml` — auto-detect Intel GPUs |
### P2: AMD GPU Display — BOUNDED PATH BUILDS (imported Linux AMD DC/TTM/core still builds and included in redbear-full (2026-04-29))
| Component | Status | Files |
|-----------|--------|-------|
| redox-drm daemon | ✅ | `local/recipes/gpu/redox-drm/source/` — DRM scheme daemon |
| AMD driver (Rust) | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/amd/mod.rs` |
| AMD DisplayCore (FFI surface) | ✅ bounded | `local/recipes/gpu/redox-drm/source/src/drivers/amd/display.rs` |
| AMD PCI stubs (dynamic) | ✅ bounded | `local/recipes/gpu/amdgpu/source/redox_stubs.c` — populated from Rust via FFI |
| AMD DC init / modeset glue (C) | ✅ bounded | `local/recipes/gpu/amdgpu/source/amdgpu_redox_main.c` — modesetting, connector detect |
| AMD glue headers | ✅ bounded | `local/recipes/gpu/amdgpu/source/redox_glue.h` — Linux compat surface for the retained path |
| GTT manager | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/amd/gtt.rs` |
| Ring buffer | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/amd/ring.rs` |
| GEM buffer mgmt | ✅ | `local/recipes/gpu/redox-drm/source/src/gem.rs` |
| DMA-BUF | ✅ | `local/recipes/gpu/redox-drm/source/src/scheme.rs` (PRIME export/import via opaque tokens) |
| Intel driver | ✅ | `local/recipes/gpu/redox-drm/source/src/drivers/intel/mod.rs` + `display.rs` |
The current retained AMD build path now produces the `amdgpu` recipe from the Red Bear glue layer
plus Rust-side driver/runtime pieces. The broad imported Linux AMD display, TTM, and amdgpu core
trees are no longer treated as compile-complete deliverables; they remain builds and included in redbear-full (2026-04-29) until
the bounded path proves a concrete need to re-introduce them.
For bounded runtime display validation, Red Bear now uses the shared
`local/scripts/test-drm-display-runtime.sh` harness, with `local/scripts/test-amd-gpu.sh` as the
AMD wrapper.
Human-readable PCI naming for AMD/Intel devices now comes from the shipped `pciids` database rather
than from hand-maintained GPU name tables in local runtime tools.
#### Historical P2 implementation snapshot
The old standalone `P2-AMD-GPU-DISPLAY.md` milestone record is now folded into this AMD-specific
reference.
Important historical P2 details that still matter:
- **Architecture:** `userspace apps -> scheme:drm -> redox-drm daemon -> AMD DC (C code,
linux-kpi) -> MMIO`
- **Build integration:** the Red Bear GPU path is rooted in `local/recipes/gpu/redox-drm/` and
`local/recipes/gpu/amdgpu/`, with PCI auto-detection from `local/config/pcid.d/amd_gpu.toml`
and the imported Linux AMD driver tree in `local/recipes/gpu/amdgpu-source/`
- **Historical P2 boot sequence:** kernel PCI init -> `pcid` AMD GPU detection -> `redox-drm`
launch -> BAR/MMIO mapping -> firmware load via `scheme:firmware` -> AMD DC init -> connector
detect / EDID -> `scheme:drm/card0` registration
- **Historical implementation closure:** the scoped P2 implementation task was compile-complete for
display-side bring-up, but hardware validation remained and still remains a separate evidence gate
That milestone should now be read through the current GPU/DRM plan and current desktop status docs
rather than as a standalone execution authority.
### Build Verification
All crates compile with `cargo check` (0 errors):
- `redox-driver-sys` ✅
- `linux-kpi` ✅
- `redox-drm` ✅
- `firmware-loader` ✅
- `evdevd` ✅
- `udev-shim` ✅
- `ext4d` ✅
### Next Steps (P2 → P3)
P2 code compiles but has NOT been validated on real hardware. Remaining:
1. Flash Red Bear OS image to USB, boot on AMD hardware with RDNA2/RDNA3 GPU
2. Verify pcid exposes `/scheme/pci/{addr}/config` and MSI-X vectors allocate
3. Verify redox-drm detects GPU, maps MMIO, initializes DC
4. Test connector detection and modesetting via scheme:drm
5. Begin P3 (POSIX gaps + evdevd) in parallel with hardware validation
---
## PHASE 3: INPUT + POSIX (4-8 weeks, parallel with Phase 2)
### P3-1: relibc POSIX Gaps (2-4 weeks)
7 APIs needed by libwayland. Same as before regardless of GPU vendor.
| API | Effort | File to create/modify |
|-----|--------|----------------------|
| signalfd/signalfd4 | ~200 lines | `relibc/src/header/signal/` |
| timerfd_create/settime/gettime | ~300 lines | `relibc/src/header/sys_timerfd/` (NEW) |
| eventfd | ~100 lines | `relibc/src/header/sys_eventfd/` (NEW) |
| F_DUPFD_CLOEXEC | ~20 lines | `relibc/src/header/fcntl/` |
| MSG_CMSG_CLOEXEC, MSG_NOSIGNAL | ~50 lines | `relibc/src/header/sys_socket/` |
| open_memstream | ~200 lines | `relibc/src/header/stdio/` |
**Patches go in**: `local/patches/relibc/`
### P3-2: evdevd Input Daemon (4-6 weeks)
Same as before. GPU vendor doesn't affect input path.
```
local/recipes/system/evdevd/
├── src/
│ ├── main.rs # Read Redox input schemes, expose /dev/input/eventX
│ ├── scheme.rs # "evdev" scheme
│ ├── device.rs # Translate Redox events → input_event
│ └── ioctl.rs # EVIOCG* ioctls
```
---
## PHASE 4: WAYLAND COMPOSITOR (4-6 weeks after P2+P3)
### P4-1: Smithay Redox Backends
```
smithay/src/backend/
├── input/redox.rs # Input backend (reads evdev via evdevd)
├── drm/redox.rs # DRM backend (uses scheme:drm)
└── egl/redox.rs # EGL display (uses Mesa)
```
### P4-2: libdrm AMD Backend
libdrm currently builds with `-Damdgpu=enabled` and `-Dintel=disabled` in the shipped recipe.
That is enough for the current AMD-oriented build-side path, but it is not yet a full Intel libdrm
feature claim. Runtime hardware validation through real GPU hardware is still pending.
---
## PHASE 5: AMD GPU ACCELERATION (16-24 weeks, parallel with P4)
> Note: this historical P5 hardware-driver track remains useful as AMD-specific implementation
> detail. In the v2.0 desktop plan
> (`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`), hardware GPU enablement is also Phase 5, so the
> numbering happens to align. The P0–P6 labels in this document refer to the historical
> hardware-enablement sequence, not the current desktop-plan phases.
### P5-1: Full amdgpu Port via LinuxKPI
This is the big one. Port the full amdgpu driver using linux-kpi headers.
**Scope**: ~666k lines of actual C code (excluding auto-generated headers)
**Approach**:
1. Port TTM memory manager first (needed by amdgpu VM)
2. Port AMD GPU VM (page table management)
3. Port command submission (ring buffers, fences)
4. Port display features beyond basic modesetting
5. Port power management (SMU interface)
6. Port video decode (VCN) — optional, later
**Estimated effort**:
- TTM: ~4 weeks
- VM + command submission: ~6 weeks
- Full driver: ~12-16 weeks
- Total with linux-kpi: **16-24 weeks**
---
## PHASE 6: KDE PLASMA (12-16 weeks after P4)
Same as previous plan (docs/05). GPU vendor doesn't affect Qt/KDE path.
1. Qt6 base + qtwayland (6-8 weeks)
2. KDE Frameworks tier 1-3 (6-8 weeks)
3. KWin + Plasma Shell (4-6 weeks)
---
## HISTORICAL P0-P6 TIMELINE
```
Week 1-6: P0 — Fix ACPI, boot on AMD bare metal
Week 3-14: P1 — redox-driver-sys + firmware-loader + linux-kpi (parallel)
Week 15-30: P2 — redox-drm + AMD DC display port (parallel)
Week 3-10: P3 — POSIX gaps + evdevd (parallel with P1)
Week 31-36: P4 — Smithay Wayland compositor (needs P2+P3)
Week 15-38: P5 — Full amdgpu via LinuxKPI (parallel with P3-P4)
Week 37-52: P6 — KDE Plasma (needs P4)
```
**With 2 developers**: ~52 weeks (~12 months) to KDE Plasma on AMD bare metal.
**With 1 developer**: ~18-24 months.
### Critical Path
```
P0 (ACPI boot)
→ P1 (driver infra) → P2 (AMD display) → P4 (Wayland) → P6 (KDE)
P3 (POSIX+input) ──┘
P5 (full amdgpu, parallel)
```
---
## DOCUMENT STATUS
> **Note (2026-04-16):** Most documents and scripts listed below have been created since this plan
> was originally written. This section is retained as a checklist rather than a to-do list.
### Documents — Creation Status
| Document | Location | Status |
|----------|----------|--------|
| This file | `local/docs/AMD-FIRST-INTEGRATION.md` | ✅ Created |
| ACPI fix guide | `local/docs/ACPI-IMPROVEMENT-PLAN.md` | ✅ Created |
| ACPI improvement plan | `local/docs/ACPI-IMPROVEMENT-PLAN.md` | ✅ Created |
| Bare metal testing log | `local/docs/BOOT-PROCESS-ASSESSMENT.md` | ✅ Created |
| Overlay usage guide | `local/AGENTS.md` | ✅ Created |
| Desktop path plan | `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | ✅ Created |
### Config Files and Scripts — Creation Status
| File | Status |
|------|--------|
| `local/scripts/fetch-firmware.sh` | ✅ Created |
| `local/scripts/build-redbear.sh` | ✅ Created (replaces build-amd.sh) |
| `local/scripts/test-baremetal.sh` | ✅ Created |
| `config/redbear-desktop.toml` | ✅ Created (replaces my-amd-desktop.toml) |
---
## ANTI-PATTERNS FOR AMD GPU ENABLEMENT
- **DO NOT** attempt a clean Rust rewrite of amdgpu — 6M lines, 5+ years
- **DO NOT** treat the historical ACPI boot-baseline work as optional when revisiting AMD bring-up — modern AMD boot depended on the RSDP/SDT/MADT/FADT path that is now already landed; see `local/docs/ACPI-IMPROVEMENT-PLAN.md` for the separate post-bring-up ownership and robustness work
- **DO NOT** forget firmware blobs — amdgpu CANNOT FUNCTION without PSP/GC/SDMA firmware
- **DO NOT** test only in QEMU — AMD GPU behavior differs significantly from VirtIO
- **DO NOT** assume Intel patterns work for AMD — AMD uses different register maps, different firmware flow
- **DO NOT** port old GCN GPUs — target RDNA2+ only (reduces scope by ~40%)
local/docs/BOOT-PROCESS-ASSESSMENT.md
-528
View File
@@ -1,528 +0,0 @@
# Red Bear OS Boot Process Assessment & Improvement Plan
**Generated:** 2026-04-23
**Updated:** 2026-04-27
**Status:** Phase 1 ✅, Phase 2 ✅, Phase 3 ✅, Phase 4 ✅ (docs + known gaps), Phase 5 ✅, Phase 6 ✅ (boot to login confirmed), Phase 7 ✅ (kernel RAM hang diagnosed + ISO organization documented)
**Scope:** Comprehensive assessment of boot completeness, mistakes, robustness, resilience, and quality
## Boot Chain Overview
```
UEFI firmware → RedBear Bootloader → Kernel (kstart→start→kmain) →
userspace_init → bootstrap (forks initfs/procmgr/initnsmgr) →
fexec init → [initfs phase] → switchroot /usr → [rootfs phase] →
login prompt (text or graphical)
```
## Phase 1: Critical Fixes Applied ✅
| ID | Severity | Fix | Evidence |
|----|----------|-----|----------|
| S1b | SHOWSTOPPER | Removed `boot_essential = true` from 3 greeter services — `#[serde(deny_unknown_fields)]` caused deserialization failure, services never loaded | `config/redbear-greeter-services.toml` — zero `boot_essential` refs remain |
| S1 | SHOWSTOPPER | Defined `05_boot-essential.target` and `12_boot-late.target` — 7 services referenced undefined targets | `config/redbear-greeter-services.toml`, `config/redbear-device-services.toml` |
| S2 | HIGH | Replaced `return` with `Vec::new()` in init config read failure — init no longer dies when rootfs config is unreadable | `init/src/main.rs:165` |
| S4 | HIGH | Removed empty `15_fatd.service` override — empty TOML caused "missing field `unit`" parse error every boot | `config/redbear-minimal.toml` |
| S5 | MEDIUM | Replaced `waitpid().unwrap()` with graceful error handling — init no longer panics on ECHILD | `init/src/main.rs:182-188` |
## Phase 2: Daemon Error Handling ✅
Replaced `unwrap()/expect()`/`assert!()` with graceful error handling across 8 boot-critical daemons + 6 graphics packages.
**Total: 215 fixes across 33 Rust source files. Zero unwrap/expect/assert in non-test production code.**
### 2A: Daemon Library + Init Spawn ✅ (10 fixes)
- `daemon/src/lib.rs`: Double-unwrap in `get_fd()` → eprintln + return -1; pipe unwrap → map_err
- `init/src/service.rs`: 3 fixes (pipe, getns, register_scheme_to_ns)
- `init/src/main.rs`: 2 fixes (filename UTF-8, setrens)
- `init/src/unit.rs`: 3 fixes — `unit()`/`unit_mut()` return `Option`, `set_runtime_target` asserts → graceful early return
- `init/src/scheduler.rs`: 2 caller updates — missing unit logs warning + skips instead of panicking
### 2B: Logd ✅ (8 fixes)
- `logd/src/main.rs`: Socket create, setrens, process_requests_blocking — match on Result<!>
- `logd/src/scheme.rs`: kernel_debug File → Option<File>, kernel_sys_log → Option, read/send errors handled
### 2C: Randd + Zerod ✅ (7 fixes)
- `randd/src/main.rs`: CPUID unwrap → Option chain, socket/setrens/process_requests, loop on error
- `zerod/src/main.rs`: Args → default "zero" + graceful exit, socket/setrens/process_requests, loop on error
### 2D: Inputd ✅ (14 fixes)
- `inputd/src/lib.rs`: 7 panic sites — from_utf8, file_name, to_str, libredox::call::open, fpath bounds check, partial vt event read, buffer size assertion
- `inputd/src/main.rs`: 7 panic sites — write!, handles.remove, deamon(), args, ControlHandle, panic! → eprintln+exit, Producer handle assertion → EBADF
### 2E: Vesad + Fbcond ✅ (34 fixes)
- `vesad/src/main.rs`: 16 fixes — FRAMEBUFFER env vars (unwrap_or_else + exit), EventQueue, env file read, subscribes, setrens, event loop (filter_map), tick error
- `vesad/src/scheme.rs`: 4 fixes — probe_connector double-unwrap, set_crtc mutex unwraps (unwrap_or_else into_inner), physmap expect
- `fbcond/src/main.rs`: 10 fixes — VT parse (filter_map), EventQueue, Socket, subscribe, event iteration, all write responses, vt get_mut, read_events, blocked get_mut
- `fbcond/src/scheme.rs`: 1 fix — fpath write! unwrap → map_err
- `fbcond/src/display.rs`: 2 fixes — V2GraphicsHandle unwrap → graceful return, dirty_fb unwrap → log error
- `fbcond/src/text.rs`: 1 fix — pop_front unwrap → unwrap_or(0)
### 2F: Init Unit Store ✅ (3 fixes)
- `unit.rs`: `unit()`/`unit_mut()` → `Option` return, `set_runtime_target()` asserts → graceful early return
- `scheduler.rs`: Callers handle None gracefully — log warning + skip instead of panicking init
## Phase 3: Boot Reliability ✅
### 3A: Boot Progress Markers ✅
Init now logs phase markers:
- `init: phase 1 — initfs boot`
- `init: starting logd`
- `init: starting runtime target`
- `init: phase 2 — switchroot to /usr`
- `init: scheduling N rootfs units`
- `init: phase 3 — rootfs services started`
- `init: boot complete — entering waitpid loop`
### 3B: Service Schema Validation (Manual) ✅
Script: `local/scripts/validate-service-files.sh`
Checks: [unit] section, [service] section, cmd field, non-empty data
Note: Manual validation script covering `redbear-*.toml` configs. Not wired into the build system — run manually after config changes. Does not cover inherited mainline configs (minimal.toml, desktop.toml).
### 3C: Getty Supervisor ✅
Init supports `respawn = true` in service TOML files. When a respawnable service's process exits, init automatically re-spawns it. All getty services across `redbear-mini`, `redbear-full`, `redbear-greeter-services`, `redbear-grub`, and `wayland` configs now have `respawn = true` set.
Implementation:
- `service.rs`: Added `respawn: bool` field to `Service` (default false). `spawn()` returns `Option<u32>` (child PID) for respawnable oneshot_async services.
- `scheduler.rs`: `Scheduler` collects respawnable (unit_id, pid) pairs in `respawn_pids` field.
- `main.rs`: Waitpid loop maintains a PID → UnitId map. On child exit, checks if the PID is respawnable and re-schedules the unit.
Usage in service TOML:
```toml
[unit]
description = "Text console"
[service]
cmd = "getty"
args = ["2"]
type = "oneshot_async"
respawn = true
```
### 3D: Greeter Crash Fallback (existing)
The fallback path via `29_activate_console.service` already activates VT2 text console independently of the greeter. If greeter crashes, text login is already available.
## Phase 4: Bare-Metal Hardening ✅ (docs + known gaps documented)
Phase 4 is documentation and gap identification. Actual bare-metal validation requires physical hardware.
All known gaps are documented with their status and required follow-up.
### USB Boot-Chain Observability
Chain: pcid-spawner → xhcid → usbhubd → usbhidd → inputd
Status: Chain exists in rootfs only. On modern hardware without PS/2 ports, USB keyboard is the only input path.
### Known Bare-Metal Gaps
| Gap | Status | Detail |
|-----|--------|--------|
| USB keyboard | Documented | 5-step chain in rootfs only; if any step fails, no keyboard |
| AMD x2APIC SMP | Patch exists | `local/patches/kernel/P0-amd-acpi-x2apic.patch` — must preserve |
| PCIe config space | Partial | Advanced PCI features need improvement |
| DMI quirks | Active | `redox-driver-sys/src/quirks/` — data-driven quirk tables |
| ACPI robustness | In progress | See `local/docs/ACPI-IMPROVEMENT-PLAN.md` |
| IRQ/low-level controllers | Active | See `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` |
### Hardware Validation Requirements
Bare-metal testing requires physical hardware. Current validation is:
- **QEMU boot**: Verified for redbear-mini and redbear-full (no panics, no parse errors, switchroot succeeds)
- **Live ISO build**: redbear-mini and redbear-grub build successfully
- **Interactive login**: Framebuffer login renders correctly (serial not available in headless QEMU)
## Phase 5: Validation Matrix ✅
### Build Verification
| Target | Build | QEMU Boot | Bare-Metal Boot | Notes |
|--------|-------|-----------|-----------------|-------|
| redbear-mini | ✅ harddrive.img (2 GB) | ✅ Login prompt | — | Framebuffer console login |
| redbear-full | ✅ harddrive.img (4 GB) | ✅ Login prompt | — | Desktop packages included |
| redbear-grub | ✅ harddrive.img | — | — | Text-only with GRUB chainload |
### Compilation Verification
- `cargo check --workspace` in base source: **0 errors**
- Individual crate checks: daemon, init, logd, randd, zerod, inputd, vesad, fbcond, console-draw, driver-graphics, fbbootlogd, graphics-ipc, ihdgd, virtio-gpud — **all pass**
- Service file validation: **53 service files pass, 0 failures**
### Unwrap/expect Audit (final)
| Daemon | Active unwrap/expect | Test-only | Status |
|--------|---------------------|-----------|--------|
| daemon/src | 0 | 0 | ✅ |
| init/src (main, service, scheduler, unit) | 0 | 0 | ✅ |
| logd/src | 0 | 0 | ✅ |
| randd/src | 0 | 8 (#[test]) | ✅ |
| zerod/src | 0 | 0 | ✅ |
| inputd/src (lib, main) | 0 | 0 | ✅ |
| vesad/src (main, scheme) | 0 | 0 | ✅ |
| fbcond/src (main, scheme, display, text) | 0 | 0 | ✅ |
| console-draw/src | 0 | 0 | ✅ |
| driver-graphics/src (lib, kms/*) | 0 | 0 | ✅ |
| fbbootlogd/src (main, scheme) | 0 | 0 | ✅ |
| graphics-ipc/src | 0 | 0 | ✅ |
| ihdgd/src (main, device/*) | 0 | 0 | ✅ |
| virtio-gpud/src (main, scheme) | 0 | 0 | ✅ |
### Validation Commands
```bash
# Build
CI=1 make all CONFIG_NAME=redbear-mini ARCH=x86_64
CI=1 make all CONFIG_NAME=redbear-full ARCH=x86_64
CI=1 make live CONFIG_NAME=redbear-mini ARCH=x86_64
CI=1 make live CONFIG_NAME=redbear-full ARCH=x86_64
# QEMU test
make qemu CONFIG_NAME=redbear-mini
# Service file validation
./local/scripts/validate-service-files.sh config/
# Clean rebuild + verify
CI=1 make cr.base CONFIG_NAME=redbear-mini ARCH=x86_64
CI=1 make all CONFIG_NAME=redbear-mini ARCH=x86_64
```
## Key Technical Findings
### Bare-Metal Boot Log Analysis (2026-04-24)
AMD machine boot log shows initfs phase starts but never completes:
- Kernel boots: ACPI, IOAPIC, timer, memory all OK
- vesad initializes: 1280x1024 at 0xA0000000 (FRAMEBUFFER_* from UEFI bootloader)
- fbbootlogd maps display
- ps2d: keyboard works, mouse BAT fails (no PS/2 mouse port — expected on modern hardware)
- pcid begins PCI enumeration
- acpid starts, AML interpreter initializes
- **MISSING**: "init: initfs drivers target step() complete" — scheduler.step() never returns
- **MISSING**: "init: phase 2 — switchroot to /usr" — rootfs phase never starts
- **MISSING**: any getty or login output
Root cause hypothesis (unproven): a service with `type = "notify"`, `type = { scheme = "..." }`,
or `type = "oneshot"` in the initfs phase does not signal readiness or does not exit,
causing init's scheduler.step() to block forever. All three service types wait synchronously
in `service.rs`. Possible blockers include:
- A `notify` service that hangs before calling `daemon::Daemon::ready()`
- A `scheme` service that hangs before calling `daemon::SchemeDaemon::ready_*()`
- An `oneshot` service like `pcid-spawner --initfs` that hangs during PCI enumeration
With the new per-service logging (Phase 6A + 6C), the next boot will show exactly which
service blocks — the last `init: starting ...` line before the hang identifies the blocker.
### Bare-Metal/QEMU Boot Log Analysis (2026-04-24, second test with Phase 6 logging)
The enhanced logging proved the initfs phase completes successfully. The actual blocker is
in the rootfs phase:
- Initfs phase: ✅ all services start and signal readiness/exit correctly
- `init: phase 2 - switchroot to /usr` ✅
- `init: scheduling 22 rootfs units` ✅
- `init: starting PCI driver spawner (pcid-spawner)` ← **BLOCKS HERE**
- pcid-spawner (rootfs, `type = "oneshot"`) spawns e1000d (ok), ihdad (fails with RIRB timeout)
- Then hangs — no further output for 30+ seconds while system is alive (keyboard works)
- Init never reaches `30_console` → getty → login
Root cause (confirmed): rootfs `00_pcid-spawner.service` uses `type = "oneshot"`, which
causes init to block until pcid-spawner exits. On real hardware and QEMU, pcid-spawner
can hang waiting for a PCI device driver that never responds, blocking the entire rootfs
phase including getty/login.
Fix: override `00_pcid-spawner.service` to `type = "oneshot_async"` in
`config/redbear-legacy-base.toml`. Drivers spawn in the background while init proceeds
to start console services. Network services that depend on specific drivers handle their
own timing (they connect to driver schemes when ready).
**Confirmed working**: Both QEMU and bare-metal boot to login prompt after this fix.
### Phase 6: Boot Visibility & Service Cleanup ✅
**Status: Confirmed working — system boots to login prompt on both QEMU and bare metal.**
**6A: Init service start logging (always visible)**
`init/src/scheduler.rs`: Service and target start messages promoted from DEBUG to always-visible.
Every service now logs `init: starting <description> (<cmd>)` before spawning and
`init: started <description> (pid <N>)` after a respawnable process is created.
**6B: Legacy init script cleanup**
`config/redbear-legacy-base.toml`:
- `00_base`: Removed dead `notify ipcd` / `notify ptyd` calls.
The `notify` binary does not exist anywhere in the build tree — these calls always failed
silently. ipcd and ptyd are started by the base recipe's systemd-style services
(`00_ipcd.service`, `00_ptyd.service`). sudo --daemon is kept because `00_sudo.service`
exists in the base recipe but is not wired into any target that gets scheduled.
The script now does tmpdir setup + sudo --daemon.
- `00_drivers`: Blanked (was redundant — pcid-spawner starts via `00_pcid-spawner.service`).
**6C: Service readiness completion logging**
`init/src/service.rs`: Added success log after each blocking wait completes:
- `notify` services: `init: <cmd> ready (notify)` after readiness byte received
- `scheme` services: `init: <cmd> ready (scheme <name>)` after scheme registered
- `oneshot` services: `init: <cmd> done (oneshot)` after process exits successfully
Combined with 6A's `init: starting ...` before spawn, the boot log now shows the full
lifecycle of every blocking service — any gap between "starting" and "ready/done" pinpoints
the blocker.
### Serde `deny_unknown_fields` Behavior
`UnitInfo` and `Service` structs use `#[serde(deny_unknown_fields)]`. Any unrecognized field in `[unit]` or `[service]` sections causes the ENTIRE service file to fail deserialization. The init system logs the error and skips the service — it never starts.
**Implication**: Service file schema changes must be coordinated between init code and config TOMLs. Manual validation (`validate-service-files.sh`) catches these in redbear-*.toml configs.
### Init `requires_weak` Semantics
`requires_weak` provides ordering, not readiness. If a dependency is missing (file not found), the scheduler treats it as satisfied (not in pending queue). Services start anyway but without ordering guarantees.
### Init `oneshot_async` Services
Services with `type = "oneshot_async"` are fire-and-forget by default. Init spawns them and doesn't track their lifecycle. However, services with `respawn = true` in their `[service]` section are tracked — if they exit, init re-schedules and re-spawns them. Getty services use `respawn = true`.
### Config Include Chain
```
redbear-full.toml → desktop.toml, redbear-legacy-base.toml, redbear-legacy-desktop.toml,
redbear-device-services.toml, redbear-netctl.toml, redbear-greeter-services.toml
desktop.toml → desktop-minimal.toml, server.toml
desktop-minimal.toml → minimal.toml
server.toml → minimal.toml
minimal.toml → base.toml
redbear-grub.toml → redbear-full.toml, redbear-grub-policy.toml
redbear-mini → redbear-minimal.toml → minimal.toml, redbear-legacy-base.toml,
redbear-device-services.toml, redbear-netctl.toml
```
### Upstream Targets (not Red Bear defined)
- `00_base.target` — `recipes/core/base/source/init.d/00_base.target`
- `10_net.target` — `recipes/core/base/source/init.d/10_net.target`
- These are installed by the base package into `/usr/lib/init.d/` and available at boot.
## Files Modified (This Assessment)
### Config Changes
- `config/redbear-greeter-services.toml` — removed boot_essential, added 05_boot-essential.target
- `config/redbear-device-services.toml` — added 12_boot-late.target
- `config/redbear-minimal.toml` — removed empty fatd override
### 2G: Console-Draw ✅ (8 fixes)
- `console-draw/src/lib.rs`: 4 DRM call unwraps → `?` operator; 3 try_into unwraps → `unwrap_or(0)`; 1 back_mut unwrap → `if let Some`
### 2H: Driver-Graphics ✅ (39 fixes)
- `driver-graphics/src/kms/connector.rs`: 3 fixes — crtc lookup unwrap, connector iterator unwrap, EDID parse unwrap → `nom::IResult::Done` match
- `driver-graphics/src/kms/objects.rs`: 2 fixes — crtcs iterator unwrap, remove_framebuffer unwrap
- `driver-graphics/src/kms/properties.rs`: 4 fixes — range asserts → log::error, mutex lock unwraps → map_err
- `driver-graphics/src/lib.rs`: 30 fixes — constructor fatal errors → process::exit(1), mutex locks → map_err/unwrap_or_else into_inner, vt lookups → ok_or, EDID parse → Done match, assert → if+return Err, try_into unwraps → graceful
### 2I: Fbbootlogd ✅ (14 fixes)
- `fbbootlogd/src/main.rs`: 10 fixes — fatal setup errors → match+exit(1), event loop errors → continue/break
- `fbbootlogd/src/scheme.rs`: 4 fixes — VT handle, graphics handle, dirty_fb ×2 → match+log
### 2J: Graphics-IPC ✅ (8 fixes)
- `graphics-ipc/src/lib.rs`: assert → if+return Err, unwrap → `?`, try_into unwraps → graceful early return
### 2K: ihdgd (Intel HD Graphics) ✅ (37 fixes)
- `ihdgd/src/device/ddi.rs`: 14 fixes — port register unwraps → match+return Err, lane loop unwraps → continue
- `ihdgd/src/device/ggtt.rs`: 2 fixes — asserts → if+return Err, reserve() returns Result
- `ihdgd/src/device/mod.rs`: 2 fixes — Drop unwrap → if let, probe_ddi expect → match+log
- `ihdgd/src/device/scheme.rs`: 8 fixes — connector/crtc lookups → match, Layout unwraps → unwrap_or_else, try_into unwraps → match
- `ihdgd/src/main.rs`: 10 fixes — EventQueue/subscribe/setrens → match+exit(1), event/IRQ loop → continue/log
- `ihdgd/src/device/pipe.rs`: 1 cascading fix — ggtt.reserve Result handling
### 2L: Virtio-GPUD ✅ (33 fixes)
- `virtio-gpud/src/main.rs`: 6 fixes — event loop, IRQ handling, scheme.tick → match+log+continue
- `virtio-gpud/src/scheme.rs`: 27 fixes — connector/crtc mutex locks → map_err/unwrap_or_else, EDID parse, cursor borrow → clone Arc, vt lookups → ok_or
### Code Changes (Phase 2 — 215 fixes across 33 Rust source files + 3 TOML config files)
- `daemon/src/lib.rs` — 2 fixes (get_fd double-unwrap, pipe unwrap)
- `init/src/main.rs` — 4 fixes (config exit, waitpid, boot progress, respawn waitpid loop)
- `init/src/service.rs` — 5 fixes (pipe, getns, register, respawn field, spawn return type)
- `init/src/unit.rs` — 3 fixes (unit/unit_mut → Option return, set_runtime_target asserts)
- `init/src/scheduler.rs` — 4 updates (handle None gracefully, respawn PID tracking, run return type)
- `logd/src/main.rs` — 3 fixes (socket, setrens, process_requests)
- `logd/src/scheme.rs` — 5 fixes (kernel_debug Option, sys_log Option, read/send)
- `randd/src/main.rs` — 4 fixes (CPUID, socket, setrens, process_requests loop)
- `zerod/src/main.rs` — 4 fixes (args, socket, setrens, process_requests loop)
- `inputd/src/lib.rs` — 7 fixes (open_display_v2 chain, fpath bounds, vt event read, buffer size)
- `inputd/src/main.rs` — 7 fixes (write, handles, daemon, args, control, Producer assertion)
- `vesad/src/main.rs` — 16 fixes (FRAMEBUFFER env, EventQueue, env file, event loop)
- `vesad/src/scheme.rs` — 4 fixes (probe_connector, set_crtc mutex, physmap)
- `fbcond/src/main.rs` — 10 fixes (VT parse, EventQueue, Socket, subscribes, writes, events)
- `fbcond/src/scheme.rs` — 1 fix (fpath write)
- `fbcond/src/display.rs` — 2 fixes (V2GraphicsHandle unwrap, dirty_fb unwrap)
- `fbcond/src/text.rs` — 1 fix (pop_front unwrap)
### Patch Preservation
- `local/patches/base/P2-daemon-hardening.patch` — 3767 lines, covers 33 Rust source files + 3 TOML configs
- `recipes/core/base/P2-daemon-hardening.patch` — symlink to local/patches
- `recipes/core/base/recipe.toml` — includes P2-daemon-hardening.patch in patches list
### New Files
- `local/scripts/validate-service-files.sh` — manual service schema validation (redbear-*.toml only)
- `local/docs/BOOT-PROCESS-ASSESSMENT.md` — this document
- `recipes/core/base/source/init.initfs.d/41_acpid.service` — acpid in initfs (boot race fix)
## Boot Procedure
### Supported compile targets
| Target | Purpose | Output |
|--------|---------|--------|
| `redbear-mini` | Minimal non-desktop (QEMU + bare metal) | `build/x86_64/harddrive.img` |
| `redbear-grub` | Text-only with GRUB boot manager (bare metal) | `build/x86_64/harddrive.img` |
| `redbear-full` | Desktop/graphics (QEMU + bare metal) | `build/x86_64/harddrive.img` |
### Build commands
```bash
# Minimal target (QEMU testing)
CI=1 make all CONFIG_NAME=redbear-mini ARCH=x86_64
# Minimal live ISO (bare-metal boot)
CI=1 make live CONFIG_NAME=redbear-mini ARCH=x86_64
# Desktop/graphics target (QEMU testing)
CI=1 make all CONFIG_NAME=redbear-full ARCH=x86_64
# Desktop/graphics live ISO (bare-metal boot)
CI=1 make live CONFIG_NAME=redbear-full ARCH=x86_64
```
### QEMU boot (harddrive.img)
```bash
# Boot the minimal target in QEMU
make qemu CONFIG_NAME=redbear-mini
# Boot with more RAM
make qemu CONFIG_NAME=redbear-mini QEMUFLAGS="-m 4G"
# Boot desktop target
make qemu CONFIG_NAME=redbear-full
```
QEMU boots from `harddrive.img` (not the live ISO). The `-serial mon:stdio` flag provides
the serial console, but Red Bear uses the framebuffer console for login — type at the
graphical console, not serial.
### Bare-metal boot (live ISO)
1. **Build the ISO:**
```bash
CI=1 make live CONFIG_NAME=redbear-mini ARCH=x86_64
```
2. **Write ISO to USB drive:**
```bash
sudo dd if=build/x86_64/redbear-live.iso of=/dev/sdX bs=4M status=progress && sync
```
Replace `/dev/sdX` with your USB device. Use `lsblk` to identify it.
3. **Boot from USB:**
- Insert USB into target machine
- Power on, enter UEFI boot menu (typically F12, F8, or Esc)
- Select the USB device as boot target
- Red Bear OS boots from UEFI → bootloader → kernel → init → login prompt
4. **Login:**
- Default user: `root`, no password
- The framebuffer console displays the login prompt after boot completes
### What happens during boot
```
UEFI firmware
→ Red Bear bootloader (loaded from EFI system partition)
→ Kernel (kstart → start → kmain)
→ userspace_init → bootstrap (forks initfs/procmgr/initnsmgr)
→ Initfs phase:
logd, inputd, vesad (framebuffer), fbcond, fbbootlogd,
ps2d (keyboard), acpid, pcid-spawner-initfs (initfs PCI drivers), lived, redoxfs
→ switchroot /usr
→ Rootfs phase:
00_base (tmpdir + sudo --daemon)
00_ipcd.service, 00_ptyd.service
00_pcid-spawner.service (async — spawns PCI drivers in background)
30_console (getty with respawn)
→ Login prompt on framebuffer console
```
### Boot log markers
The init system logs the following always-visible markers. If boot hangs, the last visible
marker identifies the blocker:
```
init: phase 1 — initfs boot
init: starting <description> (<cmd>) # before each service spawn
init: <cmd> ready (notify) # notify-type service ready
init: <cmd> ready (scheme <name>) # scheme-type service ready
init: <cmd> done (oneshot) # oneshot service exited
init: phase 2 — switchroot to /usr
init: scheduling N rootfs units
init: reached target <description>
init: phase 3 — rootfs services started
init: boot complete — entering waitpid loop
```
### Troubleshooting
| Symptom | Likely cause | Fix |
|---------|-------------|-----|
| No display output | UEFI framebuffer not provided | Try different USB port or disable CSM in UEFI settings |
| Boot hangs after "scheduling N rootfs units" | A blocking service hangs | Check last "starting" line; `pcid-spawner` was previously the blocker |
| Keyboard not working | PS/2 unavailable, USB not ready | Modern hardware uses USB — ensure xHCI controller is functional |
| No login prompt | Getty not starting | Check `30_console` service in config; verify getty respawn is set |
| "missing field `unit`" parse error | Invalid service TOML | Run `./local/scripts/validate-service-files.sh config/` |
| **No kernel output at all** (after initfs loading) | Kernel hangs before `serial::init()` finishes | **Reduce QEMU guest RAM to 2 GiB** (`-m 2048`). ≥4 GiB triggers a memory init bug on x86_64. See Phase 7. |
## Phase 7: Kernel RAM Hang Diagnosis ✅ (2026-04-27)
### Discovery
The `redbear-full` harddrive image (4 GiB) boots correctly in QEMU with **2 GiB** of guest RAM,
but **hangs silently with 4 GiB or more** — zero kernel serial output after bootloader loads
kernel and initfs.
### Evidence
| Test | RAM | Result |
|------|-----|--------|
| `redbear-full` nographic | 2 GiB | ✅ Boots: kernel output, init, services, login prompt |
| `redbear-full` nographic | 4 GiB | ❌ Hang: no kernel output, CPU spins in `pause`/`jmp` loop |
| `redbear-mini` nographic | 2 GiB | ✅ Boots normally |
| `redbear-mini` nographic | 4 GiB | ✅ Boots normally |
The kernel and initfs binaries are **identical** between `redbear-full` and `redbear-mini`
(MD5: `bb5402209aefd7d42c3adaca0682b39f` for kernel, same size for initfs). The bootloader
binary is also identical. The only difference is the GPT partition layout (RedoxFS starts at
sector 34816 in full vs 4096 in mini).
QEMU ASM trace (`-d in_asm`) at 4 GiB confirms the kernel executes instructions but **never
reaches** `info!("Redox OS starting...")` — it enters a spin-loop before `serial::init()`
completes. At 2 GiB, the kernel boots normally and produces full serial output.
### Root Cause (Analysis)
The bootloader passes different memory maps to the kernel depending on available RAM. At 2 GiB,
the memory map spans ~0x900000–0x7ED3F000 (~2 GiB). At 4 GiB, the map spans a larger range
with different reservation patterns. The kernel's `startup::memory::init()` or early SMP
bring-up code (`arch/x86_shared/start.rs`) likely encounters an overflow, bad page table
mapping, or SMP deadlock on larger memory configurations.
The spin-loop at the end of the ASM trace (`pause` + `jmp` to self) is consistent with a
spinlock wait on a memory location that never gets released — likely SMP bring-up where one
CPU waits for another that never initializes.
### Impact
| Affected | Not affected |
|----------|-------------|
| `redbear-full` with ≥4 GiB RAM | `redbear-mini` (any RAM) |
| nographic mode specifically | `redbear-grub` (any RAM) |
| Real hardware with >2 GiB RAM | All profiles at 2 GiB |
| | `make qemu` default (QEMU_MEM=2048) |
Since `make qemu` defaults to 2048 MiB and all profiles work correctly at that value, **day-to-day
development is not affected**. The bug manifests only when developers manually override RAM or
when testing on real hardware with larger memory configurations.
### Recommended Fix
Add early raw-serial output (`outb` to COM1 port 0x3F8) in `arch/x86_shared/start.rs` **before**
`device::serial::init()` as a canary to confirm serial hardware works. Then add instrumentation
around the memory map processing in `startup::memory::init()` and SMP bring-up to isolate
whether the hang is in memory init, page table setup, or multi-core initialization.
### References
- `recipes/core/kernel/source/src/arch/x86_shared/start.rs` — early kernel entry, serial init, first `info!` log
- `recipes/core/kernel/source/src/startup/memory.rs` — memory map processing
- `recipes/core/bootloader/source/src/main.rs` — bootloader `KernelArgs` construction
local/docs/COMPREHENSIVE-OS-ASSESSMENT.md
-202
View File
@@ -1,202 +0,0 @@
# Red Bear OS — Comprehensive Desktop Readiness Assessment and Improvement Plan
**Date:** 2026-04-30
**Scope:** Full desktop OS readiness: microkernel, devices, DRM, Wayland, KDE
**Status:** This document is the single source of truth, superseding all earlier individual plans.
## 1. Executive Summary
Red Bear OS has meaningful build-side progress across all major subsystems. The current state is:
| Subsystem | Status | Confidence |
|-----------|--------|------------|
| Kernel (35 syscalls, 12 schemes) | 🟢 Boot-capable | High |
| ACPI boot baseline | 🟢 Complete | High |
| IRQ/LAPIC/x2APIC | 🟢 Kernel IRQ active | High |
| PCI/MSI-X | 🟡 QEMU-proven, no hardware | Medium |
| IOMMU | 🟡 QEMU-proven | Medium |
| USB (xHCI/hub/HID/storage) | 🟡 QEMU-only | Medium |
| Storage/Network drivers | 🟢 Hardened | High |
| Audio/Input drivers | 🟡 Hardened, untested | Medium |
| Wi-Fi | 🔴 Host-tested, no hardware | Low |
| Bluetooth | 🔴 Experimental BLE-only | Low |
| **relibc (POSIX)** | 🟢 ~38 active patches, ~85% coverage | High |
| **DRM stack** | 🟡 Builds, swrast-only | Medium |
| **Qt6/KF6** | 🟡 32/32 KF6 builds, QtNetwork re-enabled | Medium |
| **Wayland** | 🟡 Libs built, compositor incomplete | Low |
| **KDE Plasma** | 🔴 Blocked (kwin stub, no full session) | Very Low |
### Bottom Line
**The OS boots, but a graphical KDE Plasma desktop session is not yet functional.** The blocker chain: ACPI shutdown robustness → hardware validation → Wayland compositor runtime → KWin → full Plasma session.
### Previously Critical Blocker — RESOLVED (2026-04-30)
**Credential syscalls** (`setgroups`, `getgroups`, `setresuid`, `setresgid`) are now implemented via the kernel proc scheme (`auth-{fd}-groups` path). `getrlimit`/`setrlimit` return userspace defaults. See `local/docs/KERNEL-IPC-CREDENTIAL-PLAN.md` for the full implementation detail. Kernel changes: `Context.groups`, `CallerCtx.groups`, Groups proc scheme handle. Relibc changes: `posix_setgroups()`/`posix_getgroups()`, real `setgroups()` impl, RLIMIT stubs. Durable patches: `local/patches/kernel/P4-supplementary-groups.patch`, `local/patches/relibc/P4-setgroups-getgroups.patch`.
---
## 2. Kernel & Core Infrastructure
### 2.1 Syscall Coverage: ~35 handled, catch-all ENOSYS
The kernel handles 35 syscalls explicitly. All others fall through to `ENOSYS`.
**Genuinely missing for desktop:**
- ~~`SYS_SETUID`, `SYS_SETGID`, `SYS_SETGROUPS`, `SYS_GETGROUPS` — credential syscalls~~ ✅ RESOLVED (2026-04-30): implemented via proc scheme `auth-{fd}-groups` path
- ~~`SYS_GETRLIMIT`, `SYS_SETRLIMIT` — resource limits~~ ✅ RESOLVED (2026-04-30): userspace stubs with reasonable defaults
- `SYS_CLOCK_SETTIME` — set system clock, ENOSYS
- `SYS_PTRACE` — debugging, handled via scheme paths
### 2.2 ACPI: Boot-complete, not release-grade
| Working | Not Working |
|---------|------------|
| RSDP/SDT, MADT, APIC/x2APIC | `acpid` startup has panic-grade `expect` paths |
| FADT shutdown via `kstop` | `_S5` derivation gated on PCI timing |
| `power_snapshot()` with AML-backed enumeration | DMAR orphaned in `acpid` source |
| EC byte-transaction access | Sleep-state beyond S5 incomplete |
### 2.3 Drivers: All hardened, no hardware validation
All 24 driver categories have been hardened (panic→error conversion). **Zero drivers have real hardware validation.** All testing is QEMU-only.
### 2.4 USB: QEMU-validated xHCI
- xHCI: 88 Red Bear patches, interrupt-driven, QEMU-only
- hub: Good quality, interrupt-driven change detection
- HID: Named `InputProducer` with legacy fallback
- Storage: `ReadCapacity16` with SCSI error handling
- **Missing**: Real hardware, EHCI/UHCI/OHCI runtime paths
### 2.5 Wi-Fi: Host-tested transport, no real hardware
- Intel PCIe transport builds, 119 tests pass
- LinuxKPI compat with 17 modules, 93 tests
- `redbear-wifictl` daemon + scheme interface
- **Blocked**: No Intel hardware available; current host has MediaTek MT7921K
### 2.6 Bluetooth: Experimental BLE-first
- Controller probe via USB, HCI init, `scheme:hciN` with full SchemeSync
- GATT client workflow (discover→read), 209 tests
- QEMU validation in progress, not stabilized
---
## 3. Desktop Stack
### 3.1 DRM/Mesa: Builds, software-rendering only
| Component | Status |
|-----------|--------|
| redox-driver-sys | ✅ Builds |
| linux-kpi | ✅ Builds |
| redox-drm | ✅ Builds (68 unit tests) |
| mesa | ✅ Builds EGL/GBM/OSMesa, **swrast only** (`-Dgallium-drivers=swrast`) |
| amdgpu | ✅ Builds + included in redbear-full |
| firmware-loader | ✅ Builds |
| iommu daemon | ✅ Builds |
**Hard blockers**: GPU command submission, fence/completion signaling, Mesa hardware winsys enablement. These require GPU-architecture-specific engineering.
### 3.2 Wayland: Libraries built, compositor incomplete
| Component | Status |
|-----------|--------|
| libwayland | ✅ Builds |
| wayland-protocols | ✅ Builds |
| smallvil (reference) | ✅ Bounded validation proof |
| cosmic-comp | Historical only |
| Full compositor runtime | ❌ Not present |
### 3.3 Qt6/KF6: 32 frameworks built, QtNetwork re-enabled
| Component | Status |
|-----------|--------|
| qtbase (Core+Gui+DBus+Wayland) | ✅ Builds |
| QtNetwork | ✅ Re-enabled (was disabled) — DNS resolver hardened |
| qtdeclarative, qtsvg, qtwayland | ✅ Builds |
| KF6 Frameworks | ✅ 32/32 built |
| kirigami | ⚠️ Stub-only |
| kf6-knewstuff | 🔄 Unblocked by QtNetwork — needs rebuild |
| kf6-kio | 🔄 Source-local QtNetwork compat headers |
### 3.4 KDE Plasma: Not booting
| Component | Status |
|-----------|--------|
| kwin | 🔄 Building (stub → real transition) |
| plasma-workspace | ❌ Blocked by kf6-knewstuff |
| plasma-desktop | ❌ Blocked by plasma-workspace |
| Full Plasma session | ❌ Not functional |
---
## 4. Implementation Action Plan
### Phase 1: Foundation Hardening (Weeks 1-3)
| # | Action | Impact |
|---|--------|--------|
| 1.1 | Fix `acpid` startup panic paths | Remove expect-based crash risks |
| 1.2 | Document AML bootstrap producer contract | Enable safe AML-free fallback |
| 1.3 | Add device driver hardware validation harness | USB, storage, network |
| 1.4 | Complete Qt6 rebuild with QtNetwork enabled | Unblock kf6-knewstuff |
### Phase 2: Core Stack Completion (Weeks 4-8)
| # | Action | Impact |
|---|--------|--------|
| 2.1 | Build KWin as real (not stub) compositor | Wayland compositor runtime |
| 2.2 | Complete Wayland compositor integration | graphical session proof |
| 2.3 | Wire KDE Plasma session components | plasma-workspace, plasma-desktop |
| 2.4 | Hardware USB validation | Real xHCI controller testing |
### Phase 3: Hardware Enablement (Weeks 9-16)
| # | Action | Impact |
|---|--------|--------|
| 3.1 | Wi-Fi real hardware validation | Intel iwlwifi proof |
| 3.2 | Bluetooth real hardware validation | USB-attached controller proof |
| 3.3 | IOMMU real hardware validation | AMD-Vi/Intel VT-d proof |
| 3.4 | ACPI sleep-state support | S3/S4 suspend/resume |
### Phase 4: Desktop Polish (Weeks 12-20)
| # | Action | Impact |
|---|--------|--------|
| 4.1 | GPU hardware rendering (if feasible) | Mesa radeonsi/intel drivers |
| 4.2 | Full KDE Plasma session runtime | Booting into graphical desktop |
| 4.3 | Desktop Wi-Fi API (D-Bus) | NetworkManager-like surface |
| 4.4 | Bluetooth desktop integration | HID, audio, file transfer |
### Kernel Blocker — RESOLVED (2026-04-30)
| # | Action | Impact | Status |
|---|--------|--------|--------|
| K1 | Engage Redox upstream for credential syscall additions in `redox_syscall` | `SYS_SETUID`, `SYS_SETGID`, `SYS_SETGROUPS` | ✅ Done via proc scheme (no crate changes needed) |
| K2 | Add kernel handler for credential syscalls | Remove ENOSYS catch-all gap | ✅ `auth-{fd}-groups` proc scheme path |
| K3 | Add RLIMIT syscalls or formally design them out | Resource limit support | ✅ Userspace stubs with defaults |
**Remaining kernel gaps:** `clock_settime`, ACPI shutdown robustness, hardware validation.
---
## 5. Documentation
### Stale Docs Deleted (this pass)
| File | Reason |
|------|--------|
| `local/docs/AMDGPU-DC-COMPILE-TRIAGE-PLAN.md` | Superseded by DRM-MODERNIZATION-EXECUTION-PLAN.md; amdgpu now builds |
### Authority Chain
| Document | Role |
|----------|------|
| `local/docs/RELIBC-COMPREHENSIVE-ASSESSMENT.md` | Canonical relibc |
| `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` | Canonical GPU/DRM |
| `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | Canonical desktop path |
| `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` | Current build/runtime truth |
| **This document** | **Canonical full-OS assessment** |
local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md
+334 -132
View File
@@ -1,180 +1,382 @@
# Red Bear OS: Console to Hardware-Accelerated KDE Desktop on Wayland
# Red Bear OS: Console → Hardware-Accelerated KDE Plasma Desktop
**Version:** 3.0 (2026-04-29)
**Replaces:** v2.2 and all prior desktop-path documents
**Status:** Canonical desktop path plan — OLW-drafted, build-verified
**Implementation status (2026-04-30):** VERIFIED SCOPE — all Redox-viable KDE packages build. Platform exclusion list defined UPFRONT: packages requiring QML JIT (QQuickWindow/QQmlEngine), Qt6::Sensors, or libinput are OUT OF SCOPE as Redox platform prerequisites. Every remaining failure is traced to these named platform gaps, not unresolved package-level issues.
**Version:** 4.0 (2026-04-30)
**Replaces:** v3.0 and all prior desktop-path documents
**Status:** Canonical comprehensive implementation plan — supersedes `COMPREHENSIVE-OS-ASSESSMENT.md`, `DESKTOP-STACK-CURRENT-STATUS.md`, and all layer-specific plans.
## Purpose
This is the single authoritative plan for the Red Bear OS path from console boot to a
hardware-accelerated KDE Plasma desktop running on Wayland. It is rewritten in v3.0 based on
a full end-to-end reassessment of every component in the chain: DRM/KMS → Mesa → Wayland
Compositor → Input/Seat → Greeter/Login → KDE Plasma.
This is the **single authoritative plan** for Red Bear OS from console boot to a hardware-accelerated
KDE Plasma desktop on Wayland. It consolidates all layer assessments, honest blocker analysis, and
the complete implementation roadmap into one document.
This plan answers: **what is the current state of every layer, what are the honest blockers,
and what must happen, in what order, to reach a usable KDE Plasma desktop.**
It answers: **what is done, what is the current state of every layer, what are the honest blockers,
and what must happen, in what order, to reach a usable KDE Plasma desktop with hardware acceleration.**
## Full Chain Assessment (2026-04-29)
## Executive Summary
### LAYER 1 — DRM/KMS
| Subsystem | Status | Evidence Class | Blockers |
|-----------|--------|---------------|----------|
| **Kernel / Credentials** | 🟢 Complete | Source + build | — |
| **ACPI boot** | 🟢 Complete | QEMU + bare-metal proof | Shutdown robustness |
| **IRQ / PCI / MSI-X** | 🟡 QEMU-proven | Source + build + QEMU | Hardware validation |
| **relibc POSIX** | 🟢 ~85% coverage | Source + Redox-target tests | Message queues, AF_UNIX |
| **DRM / KMS** | 🟡 Builds, no HW | Source + build | GPU CS ioctl backend |
| **Mesa** | 🟡 swrast only | Build (llvmpipe) | HW renderer cross-compilation |
| **Wayland compositor** | 🟡 Bounded proof | Build + QEMU | Full compositor runtime |
| **Input / Seat** | 🟢 Working | Build + QEMU | libinput deferred |
| **Greeter / Login** | 🟢 QEMU proof | Build + QEMU proof | — |
| **D-Bus** | 🟡 System bus only | Build + partial runtime | Session bus, user lookup |
| **Qt6** | 🟢 Builds | Build (Core+Gui+DBus+Wayland) | QML JIT disabled |
| **KF6 Frameworks** | 🟡 36/48 build | Build | 12 blocked (QML gate) |
| **KDE Plasma** | 🔴 Blocked | Stub + partial builds | QML JIT, KWin real build |
| **Hardware GPU** | 🔴 Not validated | Source (CS ioctl exists) | Hardware + Mesa HW cross-compile |
| **Wi-Fi / Bluetooth** | 🔴 Host-tested | Source + host tests | Hardware + native stack |
| Component | Status | Config | Notes |
|-----------|--------|--------|-------|
| redox-drm | **builds** | enabled | Intel Gen8-Gen12 + AMD device support + quirk tables; MSI-X/legacy IRQ fallback; no hardware validation |
| libdrm | **builds** | enabled | Provides libdrm_amdgpu; amdgpu device support |
| firmware-loader | **builds** | enabled | scheme:firmware; blob loading verified |
| GPU firmware | **fetched** | partial | amdgpu/i915 blobs available via fetch-firmware.sh |
| virtio-gpu | **builds** | in redox-drm | 220-line DRM/KMS backend for QEMU testing |
| CS ioctl | **protocol exists** | redox-drm scheme | Private CS submit/wait ioctls defined; hardware backend returns unavailable (GPU driver gate) | |
### Bottom Line
**Verdict**: Display infrastructure exists. Hardware rendering blocked on GPU driver backend + hardware validation (CS ioctl protocol exists).
**The OS boots to a greeter/login screen in QEMU. Software rendering works. A hardware-accelerated
KDE Plasma desktop is gated on three things: (1) Qt6Quick/QML downstream proof, (2) real KWin build,
(3) hardware GPU validation.**
### LAYER 2 — Mesa/Graphics
---
| Component | Status | Config | Notes |
|-----------|--------|--------|-------|
| mesa | **builds** | enabled | llvmpipe software renderer; EGL=on, GBM=on, GLES2=on, platform=redox |
| radeonsi (AMD HW) | **not built** | — | Not cross-compiled for Redox target |
| iris (Intel HW) | **not built** | — | Not cross-compiled for Redox target |
| OSMesa | **builds** | enabled | Off-screen software rendering |
## 1. Kernel & Core Infrastructure
**Verdict**: Software rendering works (llvmpipe). Hardware renderers need cross-compilation; CS ioctl protocol exists, backend validation deferred (hardware gate).
### 1.1 Syscall Coverage — 35 handled, credential gaps RESOLVED
### LAYER 3 — Wayland/Compositor
The kernel handles 35 syscalls explicitly. Remaining gaps:
| Component | Status | Config | Notes |
|-----------|--------|--------|-------|
| libwayland 1.24.0 | **builds** | enabled | Wayland protocol library; durability patch applied |
| wayland-protocols | **builds** | enabled | Protocol XML definitions |
| redbear-compositor | **builds, 788 lines** | enabled | Real Rust Wayland compositor; zero warnings; 3/3 tests; known limitations: heap-memory framebuffer, payload-byte SHM, NUL-terminated wire encoding |
| kwin | **stub** | enabled (but stub) | Stub — recipe downloads real KWin v6.3.4 source but build script only creates wrapper scripts + cmake config stubs; delegates to redbear-compositor; real cmake build requires Qt6Quick/QML downstream proof |
| redbear-compositor-check | **builds** | in redbear-compositor pkg | Verifies compositor socket, binaries, framebuffer |
| Syscall | Status |
|---------|--------|
| `setgroups`, `getgroups`, `setresuid`, `setresgid` | ✅ RESOLVED — proc scheme `auth-{fd}-groups` path |
| `getrlimit`, `setrlimit` | ✅ RESOLVED — userspace stubs with defaults |
| `clock_settime` | ❌ ENOSYS — needed for NTP |
| `ptrace` | 🟡 Handled via proc scheme paths |
**Verdict**: Working bounded compositor proof. Real KWin gated on Qt6Quick/QML downstream proof.
### 1.2 Kernel Credential Model (2026-04-30)
### LAYER 4 — Input/Seat
- `Context.groups: Vec<u32>` — supplementary groups per-thread with process-scope propagation
- `CallerCtx.groups` — exposed to scheme handlers for access control
- Groups proc scheme handle — `auth-{fd}-groups` read/write path
- NGROUPS_MAX=65536 enforced in kernel, non-u32-aligned writes rejected
- Fork inheritance: parent groups copied to child
- Process-scope: `setgroups()` fans out to all threads sharing `owner_proc_id`
| Component | Status | Config | Notes |
|-----------|--------|--------|-------|
| evdevd | **builds** | enabled | scheme:evdev; 65 unit tests; event device semantics verified |
| libinput | **builds, suppressed** | config: `libinput = "ignore"` | Builds but suppressed in redbear-full; evdevd handles input natively for bounded proof |
| udev-shim | **builds** | enabled | scheme:udev; device enumeration; 15 unit tests |
| seatd/seatd-redox | **builds** | enabled | meson build; 13_seatd.service wired; DRM lease via redox-drm |
| libevdev | **suppressed** | commented | build needed header |
### 1.3 ACPI — Boot-complete, not release-grade
**Verdict**: Input path works through evdevd + udev-shim. seatd wired for compositor seat access. libinput deferred (not needed for bounded proof).
| Working | Gaps |
|---------|------|
| RSDP/SDT, MADT, APIC/x2APIC | `acpid` startup has panic-grade `expect` paths |
| FADT shutdown via `kstop` | `_S5` derivation gated on PCI timing |
| EC byte-transaction access | DMAR orphaned in `acpid` source |
| AML mutex + widened accesses | Sleep-state beyond S5 incomplete |
### LAYER 5 — Greeter/Login
### 1.4 IRQ / PCI / MSI-X — QEMU-proven
| Component | Status | Config | Notes |
|-----------|--------|--------|-------|
| redbear-authd | **builds** | enabled | SHA-crypt/Argon2 auth; /etc/passwd + /etc/shadow |
| redbear-session-launch | **builds** | enabled | Session bootstrap (uid/gid/env/runtime-dir) |
| redbear-greeter | **builds** | enabled | greeterd orchestrator + Qt6/QML UI + compositor wrapper |
| redbear-sessiond | **builds** | enabled | org.freedesktop.login1 D-Bus broker (zbus) |
| dbus | **builds** | enabled | 1.16.2; system bus wired; session bus partially |
| Greeter QEMU proof | **passes** | — | GREETER_HELLO=ok, GREETER_VALID=ok, GREETER_INVALID=ok |
| redbear-kde-session | **builds** | enabled | KDE session launcher (DRM/virtual backend, plasmashell/kded6) |
- Architecturally sound: LAPIC/x2APIC, IOAPIC, MSI-X table mapping
- `redox-driver-sys`: fast PCI enumeration with capability-chain data, quirk-aware interrupt summary
- Bounded QEMU proof: MSI-X, IOMMU, xHCI IRQ
- **Blocker**: real hardware validation for all controllers
**Verdict**: Greeter/login path works end-to-end in QEMU with bounded proof. KDE session launcher ready.
### 1.5 relibc POSIX — ~85% coverage, ~38 active patches
### LAYER 6 — KDE/Plasma
| Done | Deferred |
|------|----------|
| eventfd, signalfd, timerfd (recipe-applied) | POSIX message queues |
| SysV shm, sem (activated 2026-04-29) | SysV message queues |
| waitid, named semaphores | AF_UNIX sockets |
| ifaddrs (synthetic 2-entry) | Live interface enumeration |
| fcntl F_DUPFD_CLOEXEC, MSG_CMSG_CLOEXEC | |
| getentropy, secure_getenv | |
| Component | Status | Config | Notes |
|-----------|--------|--------|-------|
| qtbase 6.11.0 | **builds** | enabled | Core+Gui+Widgets+DBus+Wayland; 7 libs + 12 plugins |
| qtdeclarative | **builds** | enabled | Qt6Quick metadata exported; QML JIT disabled for Redox; downstream proof insufficient |
| qtwayland | **builds** | enabled | Wayland QPA plugin |
| qtsvg | **builds** | enabled | SVG support |
| KDE/Plasma surface (48 recipes) | **36 build / 12 blocked** | 36 enabled in config, 12 commented/ignored. See DESKTOP-STACK-CURRENT-STATUS.md for exact breakdown. |
| kf6-kio | **builds** | enabled | HostInfo stub (direct QHostInfo::fromName replaces QtConcurrent chain) — pkgar in repo |
| kirigami | **blocked: QML gate** | ignored in config | QQuickWindow/QQmlEngine headers don't exist on Redox |
| kf6-knewstuff | **blocked** | commented out | Empty package — cmake succeeds but core source produces no libs with QtQuick off |
| kf6-kwallet | **exists in-tree** | not in enabled subset | Real API-only core wallet cmake build; QML/GPG disabled; not part of current redbear-full enabled surface |
| kf6-attica | **builds** | enabled (NEW) | Minimal core library (v6.10.0, 2.4MB pkgar in repo) |
| plasma-framework | **blocked (QML gate)** | commented out | Depends on kirigami |
| plasma-workspace | **blocked** | commented out | Depends on kf6-knewstuff payload + kwin real build |
| plasma-desktop | **blocked (transitive)** | commented out | Depends on plasma-workspace |
| kdecoration | **builds** | transitively via plasma-workspace | Window decoration library |
| kf6-kwayland | **builds** | enabled | Qt/C++ Wayland protocol wrapper |
| plasma-wayland-protocols | **builds** | transitively | XML protocol definitions |
---
**Verdict**: KDE/Plasma recipes exist (48 total). 36 build, 12 blocked with documented reasons. Real Plasma session requires resolving platform prerequisites: QML JIT for kirigami, Qt6::Sensors for kwin real build.
## 2. Hardware Enablement Stack
### LAYER 7 — Validation Infrastructure
### 2.1 DRM / KMS
| Artifact | Count | Status |
|----------|-------|--------|
| Phase 1-5 check binaries | 15+ | Zero warnings, Redox-target verified |
| Test harness scripts | 12 | Syntax-clean, guest+QEMU modes |
| Oracle verification rounds | 20+ | Phases 1-5 all verified |
| Host cargo check | 3 crates | Zero warnings |
| Redox-target build | 3 crates | Successful (make r.*) |
| Full OS build | exists | build/x86_64/redbear-full.iso + .img available; rebuild via make all CONFIG_NAME=redbear-full |
| Component | Status | Detail |
|-----------|--------|--------|
| redox-drm | 🟡 Builds | Intel Gen8-Gen12 + AMD device support; MSI-X/legacy IRQ fallback; 68 unit tests |
| libdrm | 🟡 Builds | `libdrm_amdgpu`; AMD device support |
| firmware-loader | 🟡 Builds | `scheme:firmware`; blob loading verified |
| GPU firmware | 🟡 Partial | amdgpu/i915 blobs via `fetch-firmware.sh` |
| virtio-gpu | 🟢 Builds | 220-line DRM/KMS backend for QEMU |
| CS ioctl | 🟡 Protocol exists | Private submit/wait ioctls; hardware backend returns unavailable |
| amdgpu | 🟡 Builds | Linux AMD DC/TTM/core imported; in `redbear-full` |
## Honest Blocker Classification
**Blocker**: GPU command submission backend implementation + hardware validation.
### 2.2 Mesa / Graphics
| Blocker | What's needed |
|---------|---------------|
| Qt6Quick/QML downstream proof | Qt6Quick/QML runtime proof (QML JIT disabled for Redox); blocks kirigami + real KWin + Plasma |
| Hardware GPU validation | Real AMD/Intel GPU; blocks hardware backend validation; CS ioctl protocol exists |
| Bare-metal validation | Real hardware; blocks all hardware claims |
| Component | Status | Detail |
|-----------|--------|--------|
| mesa | 🟡 Builds | llvmpipe software renderer; EGL=on, GBM=on, GLES2=on |
| radeonsi (AMD HW) | 🔴 Not built | Not cross-compiled for Redox target |
| iris (Intel HW) | 🔴 Not built | Not cross-compiled for Redox target |
| OSMesa | 🟢 Builds | Off-screen software rendering |
### Deferred (not on critical path for minimal session proof)
**Blocker**: Mesa hardware renderer cross-compilation requires CS ioctl backend + validation hardware.
| Item | Reason |
|------|--------|
| kf6-knewstuff/kwallet | real cmake builds attempted; QML disabled; not on critical path for minimal session |
| libinput | evdevd handles input natively for bounded proof; libinput builds but suppressed in config |
| libevdev | header build needed; not blocking |
### 2.3 Hardware GPU — The Big Gap
## Critical Path (updated)
| What exists | What's missing |
|-------------|---------------|
| CS ioctl protocol in redox-drm | Backend implementation (submit to GPU rings) |
| amdgpu kernel module imported | Fence/completion signaling |
| firmware blobs fetched | Mesa radeonsi/iris cross-compilation |
| MSI-X/IRQ wired | Real AMD/Intel GPU hardware for validation |
**Hardware GPU is the longest-lead item.** Estimated 12-20 weeks with hardware access.
---
## 3. Desktop Stack
### 3.1 Wayland / Compositor
| Component | Status | Detail |
|-----------|--------|--------|
| libwayland 1.24.0 | 🟢 Builds | Wayland protocol library |
| wayland-protocols | 🟢 Builds | Protocol XML definitions |
| redbear-compositor | 🟡 Bounded proof | 788-line Rust compositor; 3/3 tests; zero warnings |
| kwin | 🔴 Stub | Recipe downloads real source but only creates wrappers |
**Known compositor limitations**: SHM fd passing uses payload bytes (not SCM_RIGHTS), framebuffer uses private memory (not real vesad), wire encoding uses NUL-terminated strings (not padded Wayland format).
**Blocker**: Qt6Quick/QML downstream proof → real KWin build → full compositor runtime.
### 3.2 Input / Seat
| Component | Status | Detail |
|-----------|--------|--------|
| evdevd | 🟢 Builds | `scheme:evdev`; 65 unit tests; event semantics verified |
| udev-shim | 🟢 Builds | `scheme:udev`; device enumeration; 15 unit tests |
| seatd/seatd-redox | 🟢 Builds | DRM lease via redox-drm; service wired |
| libinput | 🟡 Deferred | Builds but suppressed; evdevd handles input natively |
| libevdev | 🟡 Deferred | Header build needed |
### 3.3 Greeter / Login — QEMU PROOF PASSES
| Component | Status | Detail |
|-----------|--------|--------|
| redbear-authd | 🟢 Builds | SHA-crypt/Argon2 auth; `/etc/passwd` + `/etc/shadow` |
| redbear-session-launch | 🟢 Builds | Session bootstrap (uid/gid/env/runtime-dir) |
| redbear-greeter | 🟢 Builds | greeterd + Qt6/QML UI + compositor wrapper |
| redbear-sessiond | 🟢 Builds | `org.freedesktop.login1` D-Bus broker (zbus) |
| Greeter QEMU proof | 🟢 Passes | GREETER_HELLO=ok, GREETER_VALID=ok |
| redbear-kde-session | 🟢 Builds | KDE session launcher |
### 3.4 D-Bus
| Component | Status | Detail |
|-----------|--------|--------|
| dbus 1.16.2 | 🟢 Builds | System bus wired; session bus partially |
| redbear-sessiond | 🟢 Builds | login1-compatible session broker |
| redbear-dbus-services | 🟢 Builds | `.service` files + XML policies |
**Known issue**: `dbus-daemon --system` fails user lookup for `messagebus` user in some runtime configurations.
### 3.5 Qt6 / KF6 / KDE Plasma
#### Qt6
| Component | Status |
|-----------|--------|
| qtbase 6.11.0 (Core+Gui+Widgets+DBus+Wayland) | 🟢 Builds — 7 libs + 12 plugins |
| qtdeclarative | 🟡 Builds — QML JIT disabled for Redox |
| qtwayland | 🟢 Builds — Wayland QPA plugin |
| qtsvg | 🟢 Builds |
| Qt6::Sensors | 🟡 Builds (dummy backend, 520KB pkgar) |
| QtNetwork | 🟢 Re-enabled — DNS resolver hardened |
#### KF6 Frameworks — 36 build, 12 blocked
**Building (36 packages):**
`karchive`, `kauth`, `kbookmarks`, `kcodecs`, `kcolorscheme`, `kcompletion`, `kconfig`,
`kconfigwidgets`, `kcoreaddons`, `kcrash`, `kdbusaddons`, `kdeclarative`, `kded6`,
`kglobalaccel`, `kguiaddons`, `ki18n`, `kiconthemes`, `kidletime`, `kio`, `kitemmodels`,
`kitemviews`, `kjobwidgets`, `knotifications`, `kpackage`, `kservice`, `ktextwidgets`,
`kwayland`, `kwidgetsaddons`, `kwindowsystem`, `kxmlgui`, `solid`, `sonnet`,
`kcmutils`, `attica`, `kdecoration`, `kglobalacceld`
**Blocked (12 packages):**
| Package | Reason |
|---------|--------|
| kirigami | QML JIT gate — `QQuickWindow`/`QQmlEngine` headers unavailable |
| plasma-framework | Depends on kirigami |
| plasma-workspace | Depends on kf6-knewstuff payload + real kwin |
| plasma-desktop | Transitive — depends on plasma-workspace |
| kf6-knewstuff | Empty package — cmake succeeds but core source produces no libs with QtQuick off |
| breeze | Build issues |
| kde-cli-tools | Build issues |
| kf6-prison | Source issues |
| kf6-kwallet | QML/GPG disabled; not in current enabled subset |
| kf6-purpose | Not attempted |
| kf6-frameworkintegration | Not attempted |
| kf6-krunner | Not attempted |
#### KWin / Plasma Session
| Component | Status |
|-----------|--------|
| kwin | 🔴 Stub — real KWin v6.3.4 source downloaded, only wrapper scripts created |
| kwin real build | 🔄 Attempted — gated on Qt6Quick/QML downstream proof |
| plasma-workspace | 🔴 Blocked |
| plasma-desktop | 🔴 Blocked (transitive) |
| Full Plasma session | 🔴 Not functional |
**The QML JIT gate**: Qt6Quick's QML engine requires a JIT compiler (`QQuickWindow`, `QQmlEngine`),
which is disabled for the Redox target. Without it, kirigami (the KDE UI framework) cannot build.
kirigami blocks plasma-framework, which blocks plasma-workspace, which blocks the full Plasma desktop.
**This is the single biggest desktop blocker.**
---
## 4. Network & Wireless
### 4.1 Wired Networking — Working
- Native Redox net stack present (`pcid-spawner` → NIC daemon → `smolnetd`/`dhcpd`/`netcfg`)
- `redbear-netctl` native command shipped
- RTL8125 autoload wired through Realtek path
- VirtIO networking in QEMU: `DBUS_SYSTEM_BUS=present`
### 4.2 Wi-Fi — Host-tested, no hardware
- Intel PCIe transport builds, 119 tests
- LinuxKPI compat with 17 modules, 93 tests
- `redbear-wifictl` daemon + scheme interface
- Bounded host-tested scan/connect/disconnect/profile flows
- **Blocker**: No Intel hardware available; MediaTek MT7921K on current host
### 4.3 Bluetooth — Experimental BLE-first
- Controller probe via USB, HCI init, `scheme:hciN`
- GATT client workflow (discover→read), 209 tests
- QEMU validation in progress
---
## 5. Honest Blocker Map
### Critical Path (ordered)
```
Layer 1 (DRM) ▸ Layer 2 (Mesa sw) ▸ Layer 3 (compositor proof) ▸
Layer 4 (input/seat) ▸ Layer 5 (greeter) ✓ ▸ Layer 6 (Plasma preflight) ✓
Environmental gate (Qt6Quick): Layer 3 (KWin runtime proof) ← Qt6Quick/QML downstream proof
Environmental gate (hardware): Layer 1 (GPU CS ioctl backend) ← hardware + Mesa HW cross-compilation
[1] Qt6Quick/QML downstream proof → unblocks kirigami → plasma-framework
[2] Real KWin build → unblocks plasma-workspace → plasma-desktop
[3] Hardware GPU validation → unblocks Mesa HW renderers
[4] ACPI shutdown robustness → release-grade ACPI
[5] Bare-metal validation → unblocks all hardware claims
```
## Current Config Surface
### Blocker Detail
`config/redbear-full.toml` enables the full desktop-capable surface including:
| # | Blocker | What's needed | Estimated effort | Hardware required |
|---|---------|---------------|-----------------|-------------------|
| 1 | QML JIT gate | Qt6Quick/QML runtime proof with JIT disabled; unblocks kirigami → 12 KDE packages | 4-6 weeks | No |
| 2 | KWin real build | Real cmake build of KWin v6.3.4; requires Qt6Quick + libinput | 2-4 weeks | No |
| 3 | Plasma session | plasma-workspace + plasma-desktop cmake builds; requires kirigami + kwin | 2-4 weeks | No |
| 4 | HW GPU backend | CS ioctl implementation → Mesa HW renderer cross-compile | 12-20 weeks | Yes — AMD/Intel GPU |
| 5 | ACPI shutdown | Remove panic paths, deterministic `_S5` | 2-4 weeks | No |
| 6 | Bare-metal proof | Real AMD/Intel hardware validation for all layers | 4-8 weeks | Yes — AMD + Intel machines |
- 36 KDE packages (33 kf6-* + kdecoration + kglobalacceld + kwin); 12 blocked/ignored with documented reasons
- kf6-attica (NEW — minimal core library, 2.4MB pkgar in repo)
- mesa + libdrm (GPU software stack)
### Path to Software-Rendered KDE Plasma (Blocks 1-3)
```
Qt6Quick proof (4-6w) → KWin real build (2-4w) → Plasma session (2-4w)
↓
Software-rendered KDE Plasma on Wayland
Total: 8-14 weeks
```
### Path to Hardware-Accelerated KDE Plasma (Blocks 1-6)
```
Software-rendered path (8-14w)
+ GPU CS ioctl backend + Mesa HW cross-compile (12-20w, parallel)
+ Hardware validation (4-8w, parallel)
↓
Hardware-accelerated KDE Plasma on Wayland
Total: 20-34 weeks
```
---
## 6. What Changed Since v3.0 (2026-04-29 → 2026-04-30)
| Change | Impact |
|--------|--------|
| Credential syscalls implemented | `setgroups`/`getgroups`/`initgroups`/RLIMIT functional. Unblocks polkit, dbus, logind, sudo. |
| Kernel groups process-scoped | `setgroups()` propagates to all process threads. NGROUPS_MAX enforced. |
| `CallerCtx.groups` added | Schemes can now check supplementary group membership for access control. |
| Kernel readback for `getgroups` | Cache is repopulated from kernel after exec/crash. |
| `setrlimit` returns proper errors | EINVAL for unknown resources, EPERM for process limits. |
---
## 7. Configuration Surface
`config/redbear-full.toml` enables the desktop-capable target:
- 36 KDE packages (33 kf6-* + kdecoration + kglobalacceld + kwin); 12 blocked/ignored
- mesa + libdrm (software GPU stack, swrast only)
- qtbase + qtdeclarative + qtwayland + qtsvg + qt6-wayland-smoke
- seatd + redbear-authd + redbear-session-launch + redbear-greeter (via redbear-mini)
- seatd + redbear-authd + redbear-session-launch + redbear-greeter
- dbus + firmware-loader + redox-drm + evdevd + udev-shim
- redbear-compositor (real Rust Wayland compositor, kwin delegates to it)
- redbear-compositor (real Rust Wayland compositor)
- plus inherited packages from redbear-mini profile
## Verification Steps (build-verified; supplementary QEMU validation) (ordered by impact)
---
1. **Rebuild full OS image** — `make all CONFIG_NAME=redbear-full` (harddrive.img for QEMU) or `make live CONFIG_NAME=redbear-full` (ISO for bare metal); existing artifacts at build/x86_64/
## 8. Evidence Model
2. **Qt6Quick/QML runtime proof** — validate Qt6Quick downstream consumers with QML JIT disabled for Redox; unblocks kirigami → real KWin → full Plasma session
3. **GPU CS ioctl implementation** — implement command submission in redox-drm; unblocks hardware rendering path
4. **Mesa HW renderer cross-compilation** — build radeonsi/iris for Redox target; requires CS ioctl for validation
5. **Real KWin build** — validate the current real KWin build with Qt6Quick/QML downstream proof; unblocks full KDE Plasma session
6. **Hardware validation** — AMD + Intel bare-metal testing for all layers
## Evidence Model
| Evidence class | What it means |
| Evidence Class | What It Means |
|----------------|---------------|
| **Source** | Code exists in tree |
| **Host build-verified** | cargo check zero warnings on Linux |
| **Redox build-verified** | make r.* successful on x86_64-unknown-redox |
| **Runtime-validated** | Exercised in QEMU or bare metal |
| **Host build-verified** | `cargo check` zero warnings on Linux |
| **Redox build-verified** | `make r.*` successful on `x86_64-unknown-redox` |
| **Runtime-validated** | Exercised in QEMU |
| **Hardware-validated** | Exercised on real AMD/Intel hardware |
Current state: Layers 1-4 are **Redox build-verified** (all 3 Red Bear crates cook on x86_64-unknown-redox). Layer 5 (greeter) is **runtime-validated** in QEMU. Layer 6 (Plasma) and hardware paths remain at build-verified preflight level.
**Current highest evidence bar reached**: QEMU runtime proof for greeter/login, bounded compositor,
D-Bus system bus, evdevd/udev-shim, DRM scheme enumeration.
**No component has hardware validation.** All hardware claims remain evidence-qualified.
---
## 9. Subsystem Plans (Reference)
This document is the authority. Subsystem plans remain for deep-dive detail:
| Plan | Covers |
|------|--------|
| `KERNEL-IPC-CREDENTIAL-PLAN.md` | Kernel credential syscalls, IPC, RLIMIT — Phases K1-K2,K4 complete |
| `IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` | PCI/IRQ/MSI-X/IOMMU quality |
| `ACPI-IMPROVEMENT-PLAN.md` | ACPI shutdown, power, sleep states |
| `RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md` | relibc IPC surface |
| `DRM-MODERNIZATION-EXECUTION-PLAN.md` | DRM/KMS modernization |
| `WAYLAND-IMPLEMENTATION-PLAN.md` | Wayland compositor stability |
| `DBUS-INTEGRATION-PLAN.md` | D-Bus architecture |
| `GREETER-LOGIN-IMPLEMENTATION-PLAN.md` | Greeter/login design |
---
## 10. Stale Docs Deleted (This Pass)
| File | Reason |
|------|--------|
| `COMPREHENSIVE-OS-ASSESSMENT.md` | Consolidated into this document |
| `DESKTOP-STACK-CURRENT-STATUS.md` | Consolidated into this document |
| `AMD-FIRST-INTEGRATION.md` | Historical — AMD and Intel are equal-priority targets |
| `HARDWARE-3D-ASSESSMENT.md` | Historical — consolidated into §2 |
| `DMA-BUF-IMPROVEMENT-PLAN.md` | Historical — consolidated into §2 |
| `INPUT-SCHEME-ENHANCEMENT.md` | Historical — consolidated into §3.2 |
| `BOOT-PROCESS-ASSESSMENT.md` | Historical — consolidated into §1 |
| `LINUX-BORROWING-RUST-IMPLEMENTATION-PLAN.md` | Historical — consolidated into §2 |
| `QT6-PORT-STATUS.md` | Historical — consolidated into §3.5 |
| `REDBEAR-INFO-RUNTIME-REPORT.md` | Historical — validation infrastructure now standard |
| `RELIBC-COMPREHENSIVE-ASSESSMENT.md` | Historical — consolidated into §1.5 |
| `RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md` | Historical — consolidated into §1.5 |
| `RELIBC-IMPLEMENTATION-PLAN.md` | Historical — consolidated into §1.5 |
local/docs/DESKTOP-STACK-CURRENT-STATUS.md
-341
View File
@@ -1,341 +0,0 @@
# Red Bear OS Desktop Stack — Current Status
**Last updated:** 2026-04-29
**Canonical plan:** `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v3.0)
**Boot improvement plan:** `local/docs/BOOT-PROCESS-IMPROVEMENT-PLAN.md` (v1.1)
**Source archival policy:** `local/docs/SOURCE-ARCHIVAL-POLICY.md` (v1.0)
## Recent Changes (2026-04-29, Wave C)
- **Validation infrastructure consistency refresh**:
- `redbear-phase4-kde-check` now detects resolved KF6 shared-library version suffixes in addition to checking library presence, session entry points, and KDE runtime markers.
- `redbear-phase5-gpu-check` now detects GPU PCI vendor/device identity from `/scheme/pci` before reporting firmware / Mesa / DRM preflight state.
- `redbear-boot-check` now provides a bounded boot-surface checker for greeter-facing service ordering, DRM readiness, compositor socket creation, and greeter hello-protocol health.
## Recent Changes (2026-04-29, Wave 7)
- **KF6 surface made more honest for Phase 3/4**:
- `kf6-kdeclarative` is enabled in `config/redbear-full.toml` (real reduced cmake build with `BUILD_WITH_QML=OFF`).
- `kf6-kio` is enabled (HostInfo stub fix — pkgar in repo).
- `kf6-knewstuff` and `kf6-kwallet` have real cmake builds; `kf6-knewstuff` remains blocked as an empty-package case, and `kf6-kwallet` exists in-tree but is not part of the current enabled `redbear-full` subset.
- Enabled count is now **36 KDE packages** (33 KF6 + kdecoration + kglobalacceld + kwin). See Current KDE Package Status table for full breakdown.
## Recent Changes (2026-04-29, Wave 6)
- **Phase 2/3 validation infrastructure**: Added bounded runtime checkers and harnesses for the next two desktop plan gates.
- `redbear-phase2-wayland-check`: Validates Wayland socket visibility, compositor process presence, bounded `wl_display.get_registry` connectivity, `/usr/lib/libEGL.so`, `/usr/lib/libGBM.so`, software-renderer evidence, and the optional `qt6-wayland-smoke` binary.
- `test-phase2-runtime.sh`: Automated `--guest` and `--qemu` Phase 2 harness using explicit binary checks plus exit-code-based expect markers.
- `redbear-phase3-kwin-check`: Validates `kwin_wayland`/`redbear-compositor` presence, `DBUS_SESSION_BUS_ADDRESS`, `dbus-send --session`, `/run/seatd.sock`, active `WAYLAND_DISPLAY`, and a bounded `wl_display.sync` roundtrip.
- `test-phase3-runtime.sh`: Automated `--guest` and `--qemu` Phase 3 harness using explicit binary checks plus exit-code-based expect markers.
- Both binaries are wired into `redbear-hwutils` Cargo packaging and the recipe staged-file list.
## Recent Changes (2026-04-29, Wave 5)
- **Phase 1 runtime validation infrastructure**: Added service presence probes and check binaries for the Phase 1 desktop substrate.
- `redbear-info --probe`: New output mode that probes Phase 1 service presence (evdevd, udev-shim, firmware-loader, redox-drm, time) via scheme enumeration. Reports per-service presence + summary line ("ALL PHASE 1 SERVICES PRESENT", "MOSTLY PRESENT, SOME GAPS", "SIGNIFICANT GAPS REMAIN").
- `redbear-phase1-evdev-check`: Validates evdev scheme enumeration, event device readability, EV_KEY/EV_REL event semantics.
- `redbear-phase1-udev-check`: Validates udev-shim device enumeration, keyboard/pointer/DRM device counts.
- `redbear-phase1-firmware-check`: Validates firmware scheme registration, blob listing, blob reading with fallback key attempts.
- `redbear-phase1-drm-check`: Validates DRM scheme registration, card enumeration, connector/mode queries.
- `relibc-phase1-tests`: Six C POSIX test programs (signalfd, timerfd, eventfd, shm_open, sem_open, waitid) exercising relibc compatibility layers as real consumers would.
- `test-phase1-runtime.sh`: Automated QEMU validation script with --guest and --qemu modes.
- All changes in local/ (durable, survives upstream refresh).
- `relibc-phase1-tests` wired into `config/redbear-full.toml`.
- **relibc-phase1-tests recipe**: Cross-compiles with Redox toolchain, installs to `/home/user/relibc-phase1-tests/` in guest filesystem.
## Recent Changes (2026-04-29, Wave 4)
- **Daemon INIT_NOTIFY panic fixed**: `P0-daemon-fix-init-notify-unwrap.patch` — replaced two `unwrap()` calls in base `daemon/src/lib.rs` (`get_fd` and `ready`) with graceful error handling. Fix survives clean source re-fetch via recipe `patches = [...]`.
- **Bootstrap workspace fix**: `P0-workspace-add-bootstrap.patch` — added `bootstrap` to workspace members in base `Cargo.toml` so initfs builds succeed.
- **Broken P2 base patches removed**: 23 broken upstream P2 patches removed from `recipes/core/base/recipe.toml` — they could not apply to current source revision and blocked fresh fetches.
- **Compositor protocol fix**: Fixed swapped size/opcode field parsing in `redbear-compositor` `dispatch()` — Wayland wire format `[size:u16][opcode:u16]` was reversed. Compositor now correctly identifies message types.
- **Compositor binary finding fix**: Wrapper script now uses `/usr/bin/redbear-compositor` (full path) to avoid PATH issues when running as `greeter` user.
- **messagebus group**: Added `[groups.messagebus]` to `config/redbear-full.toml` (gid=100, members=["messagebus"]) — D-Bus was failing to find the messagebus group.
- **Live ISO built**: `build/x86_64/redbear-full.iso` (4.0G) and `build/x86_64/redbear-full.img` built successfully with full D-Bus + Qt6 + greeter stack.
- **Source archival policy**: `local/docs/SOURCE-ARCHIVAL-POLICY.md` — new canonical policy requiring versioned filenames and fully-patched sources in archives.
- **Sources export**: 152 patches (29 recipe + 123 local) plus 40 source tarballs exported to `sources/x86_64-unknown-redox/`.
### Known Remaining Issues (Wave 4)
- **Qt Wayland shell integration**: Compositor correctly parses protocol now, but Qt6's Wayland plugin reports "Loading shell integration failed" and falls back to redox platform plugin. The compositor's event messages use native endianness (`to_ne_bytes()`) instead of Wayland's required little-endian (`to_le_bytes()`) wire format. Additionally, SHM file descriptor passing uses `read()` instead of `recvmsg()` with `SCM_RIGHTS`.
- **D-Bus session bus**: `dbus-daemon --system` starts but fails with "Could not get UID and GID for username 'messagebus'" — even though the user/group config exists, the `/etc/passwd` and `/etc/group` files in the runtime may not reflect the config entries. This blocks `redbear-sessiond` and all KDE services that depend on the session bus.
- **KF6 enablement**: superseded — see Current KDE Package Status section above. `config/redbear-full.toml` directly enables 36 KDE-related packages, but that direct config surface must not be conflated with either the archived `.pkgar` surface or the full 48-recipe local KDE set.
## Recent Changes (2026-04-28, Wave 3)
- **Bounded Wayland compositor proof** (`redbear-compositor`): 788-line Rust compositor replaces KWin stubs. Self-consistent protocol dispatch (wl_display, wl_compositor, wl_shm, wl_shell, xdg_wm_base, wl_seat). Zero warnings. 3/3 tests pass. Known limitations: SHM fd passing uses payload bytes (not Unix SCM_RIGHTS), framebuffer compositing uses private memory (not real vesad), wire encoding uses NUL-terminated strings (not padded Wayland format). Cross-compiles for Redox target. Not yet a real compositor runtime proof — bounded scaffold only.
- **DRM backend wired**: `KWIN_DRM_DEVICES=/scheme/drm/card0` wired through greeter chain in config. Runtime verification pending.
- **Intel GPU Gen8-Gen12**: Expanded from Gen12-only to Gen8-Gen12 with firmware keys (SKL/KBL/CNL/ICL/GLK/RKL/DG1/TGL/ADLP/DG2/MTL/ARL/LNL/BMG). 200+ device IDs from Linux 7.0 i915.
- **VirtIO GPU driver**: New 220-line DRM/KMS backend in redox-drm for QEMU testing.
- **Kernel 4GB RAM fix**: MEMORY_MAP overflow at 512 entries → 1024. Verified with canary chain.
- **Live ISO preload**: Capped at 1 GiB with partial preload messaging.
- **Boot daemons**: dhcpd auto-detects interface. I2C decode hardened with retry.
- **Qt6 toolchain**: `-march=x86-64 -fpermissive` for CPU compatibility and header fixes.
- **Greeter diagnostics**: Startup progress logging, QML crash-specific diagnostics.
## Purpose
This document is the **current build/runtime truth summary** for the Red Bear desktop stack.
Its job is to answer:
- what the desktop stack actually builds,
- what the tracked profiles currently expose,
- what is only build-visible,
- what is runtime-proven,
- and what still blocks a trustworthy Wayland/KDE session claim.
For the execution plan (phases, timelines, acceptance criteria), see the canonical plan above.
For subsystem planning detail, see `local/docs/WAYLAND-IMPLEMENTATION-PLAN.md`; for historical KDE rationale, see `docs/05-KDE-PLASMA-ON-REDOX.md`.
## Where We Are in the Plan
The canonical desktop plan uses a three-track model:
- **Track A (Phase 1–2):** Runtime Substrate → Software Compositor — **Phase 1 active probe and check binaries are now implemented; runtime validation in a live environment remains the exit gate**
- **Track B (Phase 3–4):** KWin Session → KDE Plasma — **blocked on Track A**
- **Track C (Phase 5):** Hardware GPU — **can start after Phase 1**
**Current position:** Build-side gates are crossed. Phase 1 (Runtime Substrate Validation) is still
the next broad desktop target, but the repo now also carries an experimental Red Bear-native
greeter/auth/session-launch stack on the `redbear-full` desktop path.
## Active Target Surface and Evidence Boundary
- The supported compile targets are `redbear-mini`, `redbear-full`, and `redbear-grub`.
- Desktop/graphics are available only on `redbear-full`.
- Older names such as `redbear-kde`, `redbear-wayland`, `redbear-minimal*`, `redbear-live-mini`,
and `redbear-live-full` still appear in historical or staging material, but they are not the
supported compile-target surface.
- The greeter/login path is currently an **experimental build/integration surface** on `redbear-full`;
it is not yet a runtime-validated end-to-end desktop-login claim.
## Status Matrix
| Area | Evidence class | Detail |
|---|---|---|
| `libwayland` | **builds** | relibc/Wayland-facing compatibility is materially stronger; 33 patches verified (was 25): signalfd, timerfd, eventfd, pthread_yield, secure_getenv, getentropy, dup3, vfork, clock_nanosleep, named-semaphores, tls-get-addr-panic-fix, fcntl-dupfd-cloexec, ipc-tests, socket-flags, syscall-0.7.4-procschemeattrs-ens-to-prio, sysv-ipc, sysv-sem-impl, sysv-shm-impl, waitid-header, open_memstream, F_DUPFD_CLOEXEC, MSG_NOSIGNAL, waitid, RLIMIT, eth0 networking, shm_open, sem_open, select-not-epoll-timeout, exec-root-bypass, tcp-nodelay, netdb-lookup-retry-fix, eventfd-mod, fd-event-tests, ifaddrs-net_if, signalfd-header, elf64-types, socket-cred, strtold-cpp-linkage, semaphore-fixes |
| Qt6 core stack | **builds** | `qtbase` (7 libs + 12 plugins), `qtdeclarative`, `qtsvg`, `qtwayland`; Qt6Quick/JIT not runtime-proven |
## Current KDE Package Status (2026-04-30)
| Category | Count | Detail |
|----------|-------|--------|
| **Directly enabled in `config/redbear-full.toml`** | 26 | 25 `kf6-*` packages plus `kwin` are directly enabled on the tracked desktop-capable target. |
| **KDE-related `.pkgar` artifacts currently visible in `repo/x86_64-unknown-redox/`** | 29 | Confirmed archived artifacts: `kf6-attica`, `kf6-extra-cmake-modules`, `kf6-karchive`, `kf6-kauth`, `kf6-kbookmarks`, `kf6-kcodecs`, `kf6-kcolorscheme`, `kf6-kcompletion`, `kf6-kconfig`, `kf6-kconfigwidgets`, `kf6-kcoreaddons`, `kf6-kcrash`, `kf6-kdbusaddons`, `kf6-kglobalaccel`, `kf6-kguiaddons`, `kf6-ki18n`, `kf6-kiconthemes`, `kf6-kio`, `kf6-kitemviews`, `kf6-kjobwidgets`, `kf6-knotifications`, `kf6-kservice`, `kf6-ktextwidgets`, `kf6-kwidgetsaddons`, `kf6-kwindowsystem`, `kf6-kxmlgui`, `kf6-solid`, `kf6-sonnet`, and `kwin`. |
| **Do not collapse these two counts** | — | The direct config surface and the archived `.pkgar` surface are not the same set: some archived KDE artifacts are dependency packages not directly enabled, and some directly enabled KDE packages are not evidenced here as `.pkgar` artifacts. |
| **Blocked: QML gate** | 1 | `kirigami` — source unconditionally includes `QQuickWindow`/`QQmlEngine`. |
| **Blocked: compilation** | 1 | `breeze` — upstream source incompatibility with the current Redox toolchain. |
| **Blocked: transitive / session assembly** | 3 | `plasma-framework` (needs `kirigami`), `plasma-workspace` (needs `kf6-knewstuff` payload + real `kwin`), `plasma-desktop` (needs `plasma-workspace`). |
| **Blocked: direct repo cook** | 1 | `kde-cli-tools` — the current config comment is `# blocked: direct repo cook fails`; do not describe this as blocked by `kf6-kio`, which is enabled. |
| **Deferred / not in the current enabled subset** | 2 | `kf6-knewstuff` remains an empty-package blocker; `kf6-kwallet` exists in-tree but is not part of the current enabled `redbear-full` subset. |
| **KWin package form** | — | The current `kwin` package is still a stub delegating to `redbear-compositor`; a real build remains gated on Qt6Quick/QML downstream proof plus the `Qt6::Sensors` / `libinput` surface. |
| **`plasma-workspace`** | — | Real cmake build exists, but it remains commented out in config and depends on `kf6-knewstuff` payload + real `kwin`. |
| **`plasma-desktop`** | — | Recipe exists, remains commented out in config, and depends on `plasma-workspace`. |
**Current tracked truth:** the local KDE recipe set under `local/recipes/kde/` contains 48 recipes. This document must distinguish the direct 36-package config surface, the currently visible archived `.pkgar` surface, and the remaining blocked/deferred items instead of collapsing them into one count.
Recipe versions tracked in this tree: KF6 frameworks v6.10.0, Plasma v6.3.4, Attica v6.10.0, KWin v6.3.4 (stub). Do not describe them as "all current upstream releases" unless that is re-verified separately.
| Mesa EGL+GBM+GLES2 | **builds** | Software path via LLVMpipe proven in QEMU; hardware path not proven |
| libdrm amdgpu | **builds** | Package-level success only |
| Input stack | **builds, enumerates** | evdevd (65 tests), udev-shim, seatd present; libinput builds but suppressed in config (`libinput = "ignore"`); libevdev commented out; end-to-end compositor input path unproven |
| D-Bus | **builds, partial** | System bus is wired on `redbear-full`; session-bus and desktop-facing service completeness remain partial. Use `local/docs/DBUS-INTEGRATION-PLAN.md` for detailed gap tracking instead of percentage claims here. |
| redbear-sessiond | **builds, scaffold (Phase 3/4 improvement active)** | org.freedesktop.login1 D-Bus session broker — Rust daemon (zbus 5), wired on the `redbear-full` desktop path; Phase 3 hard gate is TakeDevice FD passing plus PauseDevice/ResumeDevice signal emission; Priority 1 in Phase 3/4 improvement plan |
| redbear-authd | **builds** | Privileged local-user auth daemon; `/etc/passwd`/`/etc/shadow`/`/etc/group` parsing, SHA-256/SHA-512 crypt verification, bounded lockout, target-side recipe build proven |
| redbear-session-launch | **builds** | User-session bootstrap tool; runtime-dir/env setup, uid/gid handoff, dbus-run-session → `redbear-kde-session`, target-side recipe build proven |
| redbear-greeterd | **builds, experimental** | Root-owned greeter orchestrator; UI/auth socket protocol, bounded restart policy, return-to-greeter daemon logic, crate tests pass; end-to-end runtime proof still pending |
| redbear-greeter UI | **builds, experimental** | Qt6/QML unprivileged login surface now ships in-tree; bounded runtime proof remains narrower than a full trusted KDE desktop-login claim |
| TUI login fallback | **builds, boots** | `29_activate_console.service` now owns VT3 activation for `30_console.service` and `31_debug_console.service`, keeping VT2/ debug fallback consoles independent of `20_greeter.service` success |
| redbear-validation-session | **builds, bounded helper** | Still staged as a validation launcher/helper, but no longer the primary `redbear-full` display-service owner |
| Greeter runtime checker | ✅ implemented (bounded checker) | `redbear-greeter-check` asserts greeter binaries, assets, service files, socket reachability, hello protocol, invalid-login handling, and a validation-only successful-login/session-return loop inside the guest |
| Greeter QEMU harness | ✅ implemented (bounded harness) | `test-greeter-qemu.sh` boots `redbear-full`, logs in on the fallback console, and now passes the in-guest greeter checker for hello, invalid-login, and bounded successful-login return-to-greeter proof |
| redbear-notifications | ✅ Scaffold | org.freedesktop.Notifications — logs to stderr, no display integration yet |
| redbear-upower | ⚠️ scaffold / experimental | org.freedesktop.UPower — service exists, and the backing `/scheme/acpi/power` surface now performs real AML-backed enumeration, but its bootstrap preconditions and runtime proof are still too weak to call release-grade or consumer-validated; treat current enumeration as provisional until Wave 3 in `local/docs/ACPI-IMPROVEMENT-PLAN.md` closes |
| redbear-udisks | ✅ bounded real | org.freedesktop.UDisks2 — enumerates real `disk.*` schemes and partitions into read-only D-Bus objects; no fabricated mount/serial metadata |
| Phase 5 D-Bus runtime proof | ✅ implemented (bounded QEMU proof) | `redbear-phase5-network-check` + `test-phase5-network-qemu.sh` assert bounded QEMU service registration and current runtime plumbing on `redbear-full`; treat UPower as provisional until the ACPI power surface is made honest in `local/docs/ACPI-IMPROVEMENT-PLAN.md` Wave 3 |
| Phase 6 Solid readiness proof | ✅ implemented (bounded preflight) | `redbear-phase6-kde-check` + `test-phase6-kde-qemu.sh` provide bounded tooling/preflight evidence for the current `kf6-solid` surface; do not describe `kf6-solid` as disabled in `redbear-full`, because it is enabled there. |
| redbear-polkit | ✅ Scaffold | org.freedesktop.PolicyKit1 — always-permit authorization; KAuth still uses FAKE backend because PolkitQt6-1 is not packaged yet |
| redbear-dbus-services | ✅ Created | D-Bus activation files + policies staged |
| DRM/KMS | **builds** | redox-drm scheme daemon; 68 unit tests (KMS, GEM, PRIME, wire structs, scheme pure logic); no hardware runtime validation |
| GPU acceleration | **blocked** | PRIME/DMA-BUF ioctls and bounded private CS surface implemented; real vendor render CS/fence path still missing |
| validation compositor runtime | **experimental bounded scaffold** | Self-consistent protocol dispatch; 3/3 tests pass; known gaps: SHM fd passing, wire encoding, framebuffer compositing; not a real client-compatible compositor runtime proof |
| validation profile | **builds, boots** | Bounded Wayland runtime profile |
| `redbear-full` profile | **builds, boots** | Active desktop/graphics compile surface; now owns the experimental greeter/auth/session-launch integration path |
| `redbear-grub` profile | **builds** | Text-only with GRUB chainload for bare-metal multi-boot |
| `redbear-mini` profile | **builds** | Minimal non-desktop compile target |
| `redbear-hwutils` | **builds** | lspci/lsusb + Phase 1 check tools; 79 unit tests (12 cfg-gated Redox-only); zero warnings; 4 Phase 1 check binaries (evdev, udev, firmware, DRM) |
| `redbear-info --probe` | **builds** | Phase 1 service presence probes (evdevd, udev-shim, firmware-loader, redox-drm, time); reports PRESENT/ABSENT with summary; exits non-zero on gaps; 5 unit tests; bidirectional `--probe`/`--json`/`--test`/`--quirks` mutual exclusivity |
| `relibc-phase1-tests` | **builds** | Six C POSIX tests (signalfd, timerfd, eventfd, shm_open, sem_open, waitid); cross-compiled for Redox |
| `test-phase1-runtime.sh` | **builds** | Automated QEMU validation (--guest/--qemu modes) for Phase 1 substrate |
| `redbear-phase2-wayland-check` | **builds** | Phase 2 compositor proof checker: socket/process visibility, bounded `wl_display.get_registry`, EGL/GBM presence, software-renderer evidence, and optional `qt6-wayland-smoke` presence |
| `test-phase2-runtime.sh` | **builds** | Automated guest/QEMU Phase 2 harness using explicit binary checks and exit-code-only pass/fail markers |
| `redbear-phase3-kwin-check` | **builds** | Phase 3 desktop session preflight: compositor binary presence, session-bus address + `dbus-send`, seatd socket, active `WAYLAND_DISPLAY`, and bounded `wl_display.sync` roundtrip (does not validate real KWin behavior) |
| `test-phase3-runtime.sh` | **builds** | Automated guest/QEMU Phase 3 harness using explicit binary checks and exit-code-only pass/fail markers |
| | | |
| **Phase 4 (KDE Plasma) — see current KDE status section above** | | |
| KDE/Plasma surface | **direct config surface: 36 enabled** | See the Current KDE Package Status section above for the direct config count, archived `.pkgar` evidence, and blocked/deferred items; do not collapse them into a single claim. |
| `plasma-workspace` | **blocked (transitive)** | Recipe exists, blocked by `kf6-knewstuff` payload + real `kwin` |
| `plasma-desktop` | **blocked (transitive)** | Recipe exists, blocked by `plasma-workspace` |
| `plasma-framework` | **blocked (QML gate)** | Recipe exists, blocked by `kirigami` |
| `kdecoration` | **enabled in config; archive state not claimed here** | Window decoration library; keep archive claims tied to visible `.pkgar` evidence |
| `kf6-kwayland` | **enabled in config; archive state not claimed here** | Qt/C++ Wayland protocol wrapper |
| `plasma-wayland-protocols` | **recipe exists** | XML protocol definitions for kwayland/KWin |
| `kirigami` | **blocked: QML gate** | `QQuickWindow`/`QQmlEngine` headers do not exist on Redox |
| `kwin` | **stub (by design)** | cmake configs + `kwin_wayland` shim → `redbear-compositor`; real build needs Qt6Quick/QML downstream proof plus `Qt6::Sensors` / `libinput` surface |
| `kf6-attica` | **builds (in repo)** | Minimal core library (2.4MB pkgar) — NEW |
| `test-phase4-runtime.sh` | **exists** | Phase 4 KDE Plasma preflight harness (guest + QEMU modes) |
| `test-phase5-gpu-runtime.sh` | **exists** | Phase 5 hardware GPU preflight harness (guest + QEMU modes) |
| `redbear-phase4-kde-check` | **builds** | Phase 4 KDE preflight: KF6 libraries plus resolved KF6 version suffixes, plasma binaries, session entry points, and kirigami status |
| `redbear-phase5-gpu-check` | **builds** | Phase 5 GPU preflight: DRM device, GPU PCI vendor/device detection, GPU firmware, Mesa DRI drivers, and display modes |
| `redbear-boot-check` | **builds** | Boot-surface preflight: `pcid-spawner`→greeter ordering contract, DRM device readiness, compositor socket creation, and greeter hello-protocol health |
| | | |
| **Phase 5 (Hardware GPU) — driver scaffold** | | |
| `redox-drm` | **builds** | DRM scheme daemon with Intel Gen8-Gen12 + AMD device support and quirk tables; no hardware validation |
| `mesa` | **builds** | Software llvmpipe renderer; hardware renderers (radeonsi/iris) not cross-compiled |
| `amdgpu` | **builds + included in redbear-full** (2026-04-29) | Imported Linux AMD DC/TTM/core C port; bounded path compiles; enabled in config (`amdgpu = {}`) |
| `test-phase5-network-qemu.sh` | **exists** | Legacy Phase 5 network/session QEMU launcher (pre-v2.0 plan) |
## Profile View
### `redbear-full`
- **Role:** Active desktop/graphics compile target and current greeter-integration surface
- **Current truth:** Carries D-Bus, sessiond, broader integration pieces, and the experimental Red Bear-native greeter/auth/session-launch stack; VirtIO networking works in QEMU, the bounded Phase 5 network/session checker is evidence-backed there, and the repo now includes a bounded greeter checker/harness for the login surface. `redbear-validation-session` remains staged only as a bounded helper, not the active `20_display.service` owner on this target. TUI fallback (`30_console.service`/`31_debug_console.service`) is now triggered through `29_activate_console.service` and is decoupled from greeter success.
- **Use for:** Desktop integration testing, greeter/login bring-up, and bounded desktop/network plumbing validation
- **Do not overclaim:** This profile proves bounded QEMU desktop/network plumbing only. It does not by itself close the Wi-Fi implementation plan's later real-hardware Phase W5 reporting/recovery gate.
### `redbear-grub`
- **Role:** Text-only target with GRUB boot manager for bare-metal multi-boot
- **Current truth:** Follows `redbear-mini`; text-only with GRUB chainload ESP layout, no desktop/graphics
- **Use for:** Bare-metal multi-boot, recovery with GRUB menu, and install workflows requiring GRUB
### `redbear-mini`
- **Role:** Minimal non-desktop target
- **Current truth:** No desktop/graphics path; recovery and non-desktop integration surface only. TUI recovery is bound to VT activation through `29_activate_console.service` followed by `30_console.service`/`31_debug_console.service`.
- **Use for:** Minimal runtime bring-up, subsystem validation, and non-desktop packaging checks
## Current Blockers
### 1. Runtime trust trails build success (Phase 1 gate)
The repo has real build-visible desktop progress, but build success exceeds runtime confidence.
Phase 1 exists specifically to close this gap.
Phase 1 code implementation is build-verified complete (zero warnings, zero test failures, zero LSP errors). Active service probes and check binaries are in place (`redbear-info --probe`, `redbear-phase1-{evdev,udev,firmware,drm}-check`). Six C POSIX test programs for relibc compatibility layers are wired in the `relibc-phase1-tests` recipe. The automated QEMU test harness (`test-phase1-runtime.sh`) is complete and syntax-verified. Live-environment runtime validation remains pending (requires QEMU/bare metal, not available in current environment).
### 2. No complete compositor session (Phase 2 gate)
A bounded compositor initialization reaches early startup but does not complete a usable Wayland compositor session.
This blocks all desktop session work.
KWin is the sole intended compositor direction. No alternative (weston, wlroots) is in a working state. KWin recipe currently provides cmake config stubs and wrapper scripts that delegate to redbear-compositor; real KWin build requires sufficient Qt6Quick/QML build+runtime proof (qtdeclarative exports Qt6Quick metadata, but downstream QML/KWin proof is still insufficient).
### 3. Greeter/login path now exists, but runtime proof is still missing (desktop-login gate)
The repo now carries the main non-visual pieces of the Red Bear-native greeter/login plan:
- `redbear-authd`
- `redbear-session-launch`
- `redbear-greeterd`
- `redbear-greeter-services.toml`
- `redbear-greeter-check`
- `test-greeter-qemu.sh`
Current truth for that slice:
| Piece | Current state | Remaining limitation |
|---|---|---|
| `redbear-authd` | Target-side recipe build proven; unit tests cover passwd/shadow parsing, SHA-crypt and Argon2 verification, lockout, approval checks | Remaining risk is no longer auth-format handling, but broader desktop-session stability below the greeter slice |
| `redbear-session-launch` | Target-side recipe build proven; unit tests cover env/runtime-dir/argument handling, including current session environment contract | Remaining limitation is broader compositor/session stability, not the basic session-launch boundary |
| `redbear-greeterd` | Crate tests cover protocol-facing state strings, installed asset paths, bounded restart policy, and now own successful-login session launch directly after response delivery | Full desktop-login trust still depends on wider KDE runtime proof; the remaining instability is KWin compositor startup, not greeter/auth protocol wiring |
| Greeter validation helpers | `redbear-greeter-check` + `test-greeter-qemu.sh` exist and are wired for bounded runtime proof | The successful-login path is validation-only and does not replace broader KDE session proof, but the bounded QEMU greeter proof now passes |
| `redbear-greeter` packaging | Builds in-tree | Qt/QML UI binary, compositor wrapper, branded assets, and a shared login-protocol crate are present; Qt shared-plugin loading now works in the guest, while broader KWin runtime stability still remains experimental |
This means Red Bear now has a credible **bounded runtime-visible login boundary**, but not yet a
runtime-trusted general-purpose graphical login surface.
### 4. KWin recipe is a cmake stub; real KWin desktop-session proof requires Qt6Quick/QML
KWin recipe provides cmake config stubs and wrapper scripts (kwin_wayland, kwin_wayland_wrapper) that delegate to redbear-compositor. Real KWin build requires sufficient Qt6Quick/QML build+runtime proof (qtdeclarative exists but downstream QML paths unproven).
Current truth for that slice:
| Dependency | Current state | Remaining limitation |
|---|---|---|
| `libepoxy` | Real dependency | No blocker in this slice |
| `lcms2` | Real dependency | No blocker in this slice |
| `libudev` | Honest scheme-backed provider (`libudev.so`) | Hotplug monitoring remains bounded rather than full eudev parity |
| `libdisplay-info` | Honest bounded provider (`libdisplay-info.so`) | Base-EDID parsing only; CTA / DisplayID / HDR metadata remain unsupported |
Additionally, kirigami still needs more honest session-ready treatment. `kf6-kio` now has a bounded
honest reduced build, but full QtNetwork-backed KIO functionality remains unavailable.
### 5. Hardware acceleration missing GPU CS ioctl (Phase 5 gate)
PRIME/DMA-BUF buffer sharing is implemented at the scheme level, and a bounded private CS
surface now exists for shared-contract work. Real vendor render command submission and shared
fence semantics still do not exist. This still blocks hardware-accelerated rendering.
The repo now also carries a bounded in-guest display checker, `redbear-drm-display-check`, with
shell wrappers at `local/scripts/test-drm-display-runtime.sh`, `test-amd-gpu.sh`, and
`test-intel-gpu.sh`. It now covers direct connector/mode enumeration and bounded direct modeset
proof over the Red Bear DRM ioctl surface, but it is still only a runtime evidence tool until it is
exercised on real Intel and AMD hardware.
### 6. KDE Plasma session assembly blocked on QML stack (Phase 4 gate)
Kirigami is QML-gated (source unconditionally includes QQuickWindow/QQmlEngine). `kf6-kwallet` builds (API-only). `kf6-knewstuff` blocked (empty package — cmake succeeds, no libs produced). All status in Current KDE Package Status table above.
the KDE Plasma session. `kf6-kio` is now an honest reduced KIOCore-only build, so its remaining
limits have moved to the QtNetwork blocker below rather than the stub/shim bucket.
### 7. QtNetwork re-enabled for KDE network integration (2026-04-29)
QtNetwork has been re-enabled in the qtbase recipe (`-DFEATURE_network=ON`) following DNS resolver
hardening (use-after-free fix, FD leak fix, transaction ID validation, RCODE/TC handling, typed
error mapping via `P3-dns-resolver-hardening.patch`). This unblocks Qt-based network applications,
full `kf6-kio` network transparency, and KDE network-dependent features. Full build validation is
in progress.
### 8. Build system improvements completed
The build system has received targeted fixes that improve reliability:
| Component | Fix | Status |
|---|---|---|
| OnceLock panic | `get_or_init` pattern now used instead of direct `once_cell` access that could panic | Fixed |
| disk.mk error suppression | Meaningful error messages now surface instead of suppressed failures | Fixed |
| prefix.mk wget retry | Retry logic added: 3 tries with 30-second timeout | Fixed |
### 9. Init/config cleanup completed
Init service configuration has been streamlined:
- 10 unnecessary `ion -c` wrappers removed from `redbear-mini.toml` and `redbear-full.toml` (sessiond, upower, udisks, polkit, authd, echo, and others)
- D-Bus service retains `ion -c` wrapper (justified: requires shell chaining for proper daemonization)
- `redbear-login-protocol` recipe.toml created and symlinked into recipe search path
- `redbear-statusnotifierwatcher` symlinked into `recipes/system/`
## Canonical Document Roles
| Document | Role |
|---|---|
| `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` | Canonical desktop path plan (v3.0, full chain reassessment) |
| This document | Current build/runtime truth summary |
| `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` | Canonical GPU/DRM execution plan beneath the desktop path |
| `local/docs/QT6-PORT-STATUS.md` | Qt/KF6/KWin package-level build status |
| `local/docs/AMD-FIRST-INTEGRATION.md` | AMD-specific hardware/driver detail |
| `local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` | Canonical Wayland subsystem plan |
| `docs/05-KDE-PLASMA-ON-REDOX.md` | Historical KDE design rationale |
| `local/docs/PROFILE-MATRIX.md` | Profile roles and support-language reference |
## Bottom Line
The Red Bear desktop stack has crossed major build-side gates and one bounded runtime gate, but the KDE documentation needs stricter separation between enabled config surface, archived artifact surface, and blocked/deferred recipes:
- The tracked Qt6 desktop stack (`qtbase`, `qtdeclarative`, `qtwayland`, `qtsvg`) builds.
- `config/redbear-full.toml` directly enables 36 KDE-related packages, while `repo/x86_64-unknown-redox/` currently shows 29 KDE-related `.pkgar` artifacts; do not collapse those into one claim.
- Three supported compile targets exist, with desktop/graphics on `redbear-full`.
- The Red Bear-native greeter/login path has a bounded passing QEMU proof (`GREETER_HELLO=ok`, `GREETER_INVALID=ok`, `GREETER_VALID=ok`), and `20_greeter.service` is currently wired to `/usr/bin/redbear-greeterd` in `config/redbear-full.toml`.
- relibc compatibility is materially stronger than before.
- Phase 1 test coverage is comprehensive: 300+ unit tests across all Phase 1 daemons (evdevd 65, udev-shim 15, firmware-loader 24, redox-drm 68, redbear-hwutils 79 host + 12 Redox-cfg-gated, bluetooth/wifi 209); service presence probes (`redbear-info --probe`) and 4 check binaries (`redbear-phase1-{evdev,udev,firmware,drm}-check`) validate Phase 1 substrate; 6 C POSIX tests (`relibc-phase1-tests`) exercise relibc compatibility layers.
- `kwin` remains a stub delegating to `redbear-compositor`; a real build remains gated on Qt6Quick/QML downstream proof plus the `Qt6::Sensors` / `libinput` surface.
The remaining work is **platform prerequisite resolution** (QML JIT, Qt6::Sensors, libinput ports) before full KDE Plasma session can be assembled. Phase 1-2 runtime validation continues via QEMU.
Phase 1 (Runtime Substrate Validation) has comprehensive test coverage; the remaining gate is live-environment runtime validation. The key boundary for Phase 2 is: no compositor session proof exists. The key boundary for Phase 3-4 is: platform prerequisites (QML JIT, Qt6::Sensors, libinput) must be resolved before KWin real build and full Plasma session.
local/docs/DMA-BUF-IMPROVEMENT-PLAN.md
-441
View File
@@ -1,441 +0,0 @@
# Red Bear OS: DMA-BUF Improvement Plan
**Date**: 2026-04-16
**Status**: historical DMA-BUF bring-up plan, partially superseded by the current DRM shared-core work. PRIME import/export and bounded private-CS groundwork are now implemented; real vendor render/fence completion is still blocked.
> **Planning authority note (2026-04-18):** this file remains the detailed DMA-BUF/PRIME reference,
> not the canonical GPU/DRM execution plan. Use `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`
> for current sequencing and acceptance criteria.
**Scope**: Cross-process GPU buffer sharing for hardware-accelerated KDE Plasma on Wayland
## Bottom Line
Redox kernel already has the three primitives needed for DMA-BUF-style cross-process buffer
sharing:
1. **`Provider::FmapBorrowed`** + **`Grant::borrow_fmap()`** — kernel mechanism for borrowing
pages from a scheme into another process's address space, mapping the same physical frames
(zero-copy). Source: `kernel/source/src/context/memory.rs:1157`, `memory.rs:1401`.
2. **`sendfd`** syscall — passes file descriptors between processes via scheme IPC. Both
processes hold the same `Arc<LockedFileDescription>`. Source: `kernel/source/src/syscall/fs.rs:415`.
3. **`PhysBorrow`** in `scheme:memory` — maps physical addresses directly into process space
(already used for GPU registers/BARs). Source: `kernel/source/src/scheme/memory.rs`.
No new kernel syscalls or scheme types are needed for v1. The work is entirely in userspace:
redox-drm scheme daemon, libdrm, and Mesa.
## Architecture Principle
**DMA-BUF is a sharing and lifetime contract, not a global allocator.**
Linux `dma_buf` is an exporter/importer contract. The exporter owns allocation and controls
lifetime. The importer gets shared access. Red Bear OS follows the same model:
- **Allocation stays with `redox-drm`** (the exporter). `DmaBuffer::allocate()` in `gem.rs`
already allocates physically-contiguous system RAM.
- **Sharing uses scheme-backed fds + `sendfd`**. No synthetic fd numbers. No global registry.
- **Mapping uses `FmapBorrowed`**. The kernel maps the same physical pages into the importer's
address space — zero-copy.
## Data Flow
```
Process A (GPU client, e.g. Mesa/radeonsi)
1. open("/scheme/drm/card0")
2. DRM_IOCTL_GEM_CREATE → allocate GPU buffer ← EXISTS
3. DRM_IOCTL_PRIME_HANDLE_TO_FD → get opaque export token ← IMPLEMENTED
4. open("/scheme/drm/card0/dmabuf/{token}") → get scheme fd ← IMPLEMENTED
5. sendfd(socket, fd) → pass fd to compositor ← KERNEL EXISTS
Process B (compositor, e.g. KWin)
6. recvfd(socket) → receive the fd ← KERNEL EXISTS
7. DRM_IOCTL_PRIME_FD_TO_HANDLE → import as local GEM ← IMPLEMENTED
7. mmap(fd, size) → kernel uses FmapBorrowed ← KERNEL EXISTS
8. Both processes see same physical pages ← ZERO-COPY
```
Steps 1-2 are already working. PRIME import/export is also now implemented in `redox-drm`, and
the shared DRM core now includes a bounded private command-submission surface for contract
hardening. Real vendor render/fence completion is still missing.
## Current State
### What Exists
| Component | Status | Detail |
|-----------|--------|--------|
| GEM_CREATE ioctl | ✅ Working | `DmaBuffer::allocate()` in `gem.rs`, physically contiguous system RAM |
| GEM_CLOSE ioctl | ✅ Working | Ownership tracking, reference counting, safe cleanup |
| GEM_MMAP ioctl | ✅ Working | Returns virtual address for mmap_prep |
| KMS/modesetting ioctls | ✅ Working | 16 KMS ioctls, CRTC/connector/encoder/plane |
| Kernel FmapBorrowed | ✅ Exists | `Provider::FmapBorrowed` at `memory.rs:1157`, `Grant::borrow_fmap()` at `memory.rs:1401` |
| Kernel sendfd | ✅ Exists | `SYS_SENDFD` at `syscall/fs.rs:415`, passes `Arc<LockedFileDescription>` |
| Kernel PhysBorrow | ✅ Exists | `scheme:memory` physical address mapping |
| libdrm `__redox__` | ✅ Full | Opens `/scheme/drm`, dispatches KMS + PRIME ioctls via `redox_fpath` |
### What Is Missing
| Component | Status | Impact |
|-----------|--------|--------|
| PRIME_HANDLE_TO_FD | ✅ Implemented | Opaque export tokens via prime_exports map |
| PRIME_FD_TO_HANDLE | ✅ Implemented | Token lookup via prime_exports, adds to owned_gems |
| libdrm PRIME/GEM dispatch | ✅ Implemented | __redox__ wrappers in drmPrimeHandleToFD/drmPrimeFDToHandle |
| Mesa Redox winsys | 🚧 Scaffolding | Stubs compile but do not render — blocked on GPU CS |
| GPU command submission | ⚠️ Bounded shared surface only | Shared private-CS contract exists; no real vendor render ioctl/ring programming yet |
| GPU fence/signaling | ❌ Not implemented | No GPU completion notification |
### What Was Cleaned Up (Historical Session)
The old fake PRIME implementation used synthetic fd numbers starting at 10,000 that were not real
kernel file descriptors. Other processes could not resolve them. Oracle caught this across 4
verification rounds. The cleanup and follow-up hardening:
- Removed `exported_dmafds` tracking from Handle struct
- Removed the old fake PRIME synthetic-fd bookkeeping. Imported GEM tracking still exists in the current honest PRIME path.
- Removed DMA-BUF methods from `GpuDriver` trait and AMD/Intel driver impls
- Removed `DmabufManager` from `GemManager`
- Removed `mod dmabuf` from `main.rs`
- Removed PRIME wire structs (`DrmPrimeHandleToFdWire`, `DrmPrimeFdToHandleWire`)
- PRIME handlers are now implemented in the current scheme path with non-guessable export tokens; only unsupported fake sync/render paths return `EOPNOTSUPP`.
- Removed all `#[allow(dead_code)]` from fake bookkeeping
## Phased Implementation
### v1: System RAM, Linear, Single GPU (Target: working PRIME)
**Current note:** the PRIME/export-import milestones in this section are largely complete in the
live `redox-drm` scheme. The remaining value of this document is the dependency narrative and the
later DMA-BUF / winsys / fencing roadmap, not the claim that PRIME is still unimplemented.
**Goal**: A compositor (KWin) can import a buffer rendered by a GPU client (Mesa) and display it.
All buffers in system RAM, linear layout, single GPU.
**Duration estimate**: 6-10 weeks (2 developers)
#### Step 1: Delete dead dmabuf.rs
Remove `local/recipes/gpu/redox-drm/source/src/dmabuf.rs`. It is dead code — `mod dmabuf` was
removed from `main.rs` but the file still exists.
**Effort**: trivial
#### Step 2: Implement PRIME export in redox-drm
When `PRIME_HANDLE_TO_FD` is called:
1. Look up the GEM handle in the calling fd's `owned_gems`
2. Validate ownership (same as GEM_MMAP check)
3. Generate an opaque export token and store `prime_exports[token] = gem_handle`
4. Return the token to the caller (NOT a scheme fd or GEM handle)
The client then opens `/scheme/drm/card0/dmabuf/{token}` to get a real scheme fd. The open
handler validates the token against `prime_exports`, creates a `NodeKind::DmaBuf` scheme handle,
and bumps the GEM export refcount. When that scheme fd is closed, the refcount is dropped.
Key design: export tokens are opaque, non-guessable identifiers, not synthetic fd numbers or raw GEM handles.
The `prime_exports` map resolves tokens to GEM handles. Tokens are cleaned up when the last
export ref for a GEM handle is dropped.
**Changes to `scheme.rs`**:
- Add `NodeKind::DmaBuf { gem_handle, export_token }` variant
- Add `prime_exports: BTreeMap<u32, GemHandle>` and `next_export_token: u32`
- `PRIME_HANDLE_TO_FD` handler: validate ownership → generate token → store in prime_exports → return token
- `PRIME_FD_TO_HANDLE` handler: receive token → look up in prime_exports → add GEM to caller's `owned_gems`
- `open()` handler: accept `"card0/dmabuf/{token}"` path → validate token → create DmaBuf node → bump export ref
- `mmap_prep()` handler: for DmaBuf nodes, return GEM physical address
**Changes to `driver.rs`**:
- No changes needed. GEM operations stay on the trait as-is. PRIME is a scheme-level concern,
not a driver-level concern.
**Effort**: 1-2 weeks
#### Step 3: Add reference counting for shared GEM objects
When a GEM buffer is exported via PRIME, multiple scheme fds may reference it. The `close()` path
must only call `driver.gem_close()` when ALL references (original GEM + all exported fds) are gone.
**Changes**:
- Add `gem_refcounts: BTreeMap<GemHandle, usize>` to `DrmScheme`
- Increment on export, decrement on close of DmaBuf fd
- `gem_close()` checks refcount before calling driver
**Effort**: 3-5 days
#### Step 4: Validate with a two-process reproducer
Build a minimal test that:
1. Process A opens `/scheme/drm/card0`, creates a GEM buffer, writes a pattern
2. Process A exports via PRIME_HANDLE_TO_FD
3. Process A sends the fd to Process B via `sendfd` (or equivalent scheme IPC)
4. Process B receives the fd, imports via PRIME_FD_TO_HANDLE
5. Process B mmaps the imported handle and reads the pattern
6. Verify both processes see the same physical pages (same data, zero-copy)
This validates the full chain: redox-drm → scheme fd → sendfd → import → mmap → FmapBorrowed.
**Effort**: 1 week
#### Step 5: libdrm Redox PRIME/GEM dispatch
libdrm already has `__redox__` conditionals. Add dispatch for:
- `drmPrimeHandleToFD()` → send `PRIME_HANDLE_TO_FD` ioctl to `/scheme/drm`
- `drmPrimeFDToHandle()` → send `PRIME_FD_TO_HANDLE` ioctl
- `drmPrimeClose()` → close the exported/imported fd
- `drmGemHandleToPrimeFD()` / `drmPrimeFDToGemHandle()` — aliases for the above
The libdrm WIP recipe is at `recipes/wip/x11/libdrm/`. The `__redox__` handling already opens
`/scheme/drm` and has ioctl dispatch infrastructure. The gap is PRIME/GEM-specific ioctl codes.
**Effort**: 1-2 weeks
#### Step 6: Mesa Redox winsys (compile-time scaffolding)
Add `src/gallium/winsys/redox/` to Mesa that:
- Opens the DRM scheme
- Allocates GEM buffers via `GEM_CREATE`
- Exports them via `PRIME_HANDLE_TO_FD`
- Imports shared buffers via `PRIME_FD_TO_HANDLE`
- Maps them via `mmap` (which triggers `FmapBorrowed`)
Pattern: similar to `winsys/amdgpu/drm/` but using Redox scheme IPC. This is scaffolding — it
compiles but cannot render without GPU command submission (Step 8).
Split into:
- **6a**: Compile-time winsys structure, buffer allocation, PRIME export/import
- **6b**: Runtime buffer-sharing enablement (depends on step 4 validation)
**Effort**: 3-4 weeks
### v2: VRAM/GTT Placement, Tiling, Multi-GPU
**Goal**: Buffers can live in VRAM with GTT aperture access. Tiled/modifier support for
scanout-optimized layouts. Multi-GPU buffer sharing.
**Duration estimate**: 8-12 weeks (after v1)
- AMD GTT/VRAM placement via `amdgpu_gtt_mgr` / `amdgpu_vram_mgr` equivalents
- Intel GGTT/PPGTT population for imported buffers
- DRM format modifiers: `DRM_FORMAT_MOD_LINEAR` + vendor-specific tiling
- Multi-GPU: each GPU has its own `redox-drm` instance, PRIME between them
- This tier requires the AMD/Intel driver GTT programming that is currently partial
### v3: Fencing, Explicit Sync, Vulkan
**Goal**: GPU fence objects for render/scanout synchronization. Explicit sync protocol for
Wayland. Vulkan driver support.
**Duration estimate**: 12-16 weeks (after v2)
- `dma_fence` equivalent: kernel waitable event per page-flip or command submission
- `sync_file` equivalent: fd-backed fence that can be passed between processes
- Wayland `zwp_linux_explicit_synchronization_v1` protocol in compositor
- Vulkan `VK_KHR_external_memory` / `VK_KHR_external_semaphore` backed by DMA-BUF fds
- AMD: fence through ring buffer writeback + IRQ
- Intel: fence through seqno writeback + IRQ
## Dependency Graph
```
Step 1 (delete dmabuf.rs)
→ no dependency, do immediately
Step 2 (PRIME export/import in scheme)
→ depends on: nothing
→ enables: steps 3, 4, 5
Step 3 (refcount for shared GEM)
→ depends on: step 2
→ enables: step 4
Step 4 (two-process reproducer)
→ depends on: steps 2, 3
→ validates: the full chain works
Step 5 (libdrm dispatch)
→ depends on: step 2 (ioctl protocol defined)
→ can start in parallel with steps 3-4
Step 6 (Mesa winsys)
→ depends on: step 5 (libdrm API available)
→ 6a can start once step 2 protocol is defined
→ 6b should wait for step 4 validation
```
Steps 5 and 6a can proceed in parallel with steps 3-4 once step 2 is done.
## What This Does NOT Cover
This plan covers **cross-process buffer sharing** (the DMA-BUF/PRIME contract). It does not cover:
| Out of scope | Where it lives |
|-------------|----------------|
| GPU command submission (CS ioctl) | `HARDWARE-3D-ASSESSMENT.md` Tier 2 |
| GPU fence/signaling | `HARDWARE-3D-ASSESSMENT.md` Tier 2 |
| Mesa hardware Gallium driver (radeonsi/iris) | `HARDWARE-3D-ASSESSMENT.md` Tier 1 |
| AMD ring buffer programming | `local/recipes/gpu/amdgpu/` |
| Intel render ring programming | `local/recipes/gpu/redox-drm/source/src/drivers/intel/` |
| Mesa EGL platform extension for DRM | `HARDWARE-3D-ASSESSMENT.md` Tier 3 |
PRIME/DMA-BUF is a **prerequisite** for hardware-accelerated rendering, but it is not sufficient
by itself. The render pipeline (command submission + fencing + Mesa driver) is tracked separately
in `HARDWARE-3D-ASSESSMENT.md`.
## Why Not a Kernel DMA-BUF Scheme
Linux has a global `dma-buf` kernel subsystem with its own fd type. Red Bear OS does NOT need this
because:
1. **`redox-drm` IS the exporter.** In Linux, any kernel subsystem can export a dma-buf. In Redox,
only the DRM scheme exports GPU buffers. There is no need for a generic kernel dma-buf layer.
2. **Scheme fds ARE the sharing mechanism.** In Linux, dma-buf has its own fd type with special
mmap semantics. In Redox, scheme file descriptors already support `fmap_prep` → `FmapBorrowed`.
The kernel maps the same physical pages. No new fd type needed.
3. **`sendfd` IS the fd passing mechanism.** In Linux, fd passing uses SCM_RIGHTS over Unix
sockets. In Redox, `sendfd` passes `Arc<LockedFileDescription>` via scheme IPC. Same result.
If a future use case requires sharing non-DRM buffers (e.g., camera frames, video decode output),
a separate `scheme:dmabuf` could be created. But for GPU buffer sharing, the DRM scheme is
sufficient.
## Wire Protocol Design
### PRIME_HANDLE_TO_FD
Request (from libdrm client):
```c
struct DrmPrimeHandleToFdWire {
uint32_t handle; // GEM handle to export
uint32_t flags; // DRM_CLOEXEC | DRM_RDWR (hints, not critical for v1)
};
```
Response:
```c
struct DrmPrimeHandleToFdResponseWire {
int32_t fd; // opaque export token (NOT a process fd or GEM handle)
uint32_t _pad;
};
```
The scheme internally:
1. Validates handle ownership
2. Generates an opaque non-guessable export token
3. Stores `prime_exports[token] = gem_handle`
4. Returns the token as `fd`
The client then opens `/scheme/drm/card0/dmabuf/{token}` to get a real scheme fd.
The open handler validates the token, creates a DmaBuf scheme handle, and bumps
`gem_export_refs`. When that scheme fd is closed, the ref is dropped.
### PRIME_FD_TO_HANDLE
Request (from libdrm client):
```c
struct DrmPrimeFdToHandleWire {
int32_t fd; // opaque export token (extracted via redox_fpath on dmabuf fd)
uint32_t _pad;
};
```
Response:
```c
struct DrmPrimeFdToHandleResponseWire {
uint32_t handle; // GEM handle for the imported buffer
uint32_t _pad;
};
```
The scheme internally:
1. Looks up the export token in `prime_exports` → gets the GEM handle
2. Validates the token exists
3. Adds the GEM handle to the caller's `owned_gems`
4. Returns the GEM handle
### open() path extension
```rust
// Existing paths:
"card0" → NodeKind::Card
"card0Connector/{id}" → NodeKind::Connector(id)
// Export token path (validated against prime_exports):
"card0/dmabuf/{token}" → NodeKind::DmaBuf { gem_handle, export_token: token }
```
### redox_fpath() for DmaBuf
```rust
NodeKind::DmaBuf { export_token, .. } => format!("drm:card0/dmabuf/{export_token}")
```
### Token cleanup
When the last export ref for a GEM handle is dropped:
```rust
fn drop_export_ref(&mut self, gem_handle: GemHandle) {
// ... decrement refcount ...
if remove_entry {
self.gem_export_refs.remove(&gem_handle);
self.prime_exports.retain(|_, &mut h| h != gem_handle);
}
}
```
When a GEM is destroyed via any path (GEM_CLOSE, DESTROY_DUMB, handle close, fb reap),
`prime_exports` entries are pruned:
- `maybe_close_gem()`: central helper prunes tokens on successful `driver.gem_close()`
- `GEM_CLOSE` / `DESTROY_DUMB`: explicit `prime_exports.retain()` after direct `driver.gem_close()`
- `PRIME_FD_TO_HANDLE`: `gem_size()` liveness check removes stale token on failure
- `open("card0/dmabuf/{token}")`: `gem_size()` liveness check removes stale token on failure
## Files to Modify
| File | Change | Status |
|------|--------|--------|
| `local/recipes/gpu/redox-drm/source/src/dmabuf.rs` | **DELETED** | ✅ |
| `local/recipes/gpu/redox-drm/source/src/scheme.rs` | DmaBuf nodes, opaque export tokens, PRIME handlers, refcount cleanup, stale token cleanup | ✅ |
| `local/recipes/gpu/redox-drm/source/src/gem.rs` | No changes (GEM operations unchanged) | — |
| `local/recipes/gpu/redox-drm/source/src/driver.rs` | No changes (PRIME is scheme-level) | — |
| `local/recipes/gpu/redox-drm/source/src/main.rs` | No changes (already clean) | — |
| `recipes/wip/x11/libdrm/source/xf86drm.c` | `redox_fpath()` + export token dmabuf path + `sys/redox.h` | ✅ |
| `recipes/libs/mesa/source/src/gallium/winsys/redox/drm/` | 4 scaffolding files (compile-time only) | ✅ |
| `local/recipes/tests/redox-drm-prime-test/` | Test reproducer recipe + Rust binary (incl. stale token test) | ✅ |
| `local/docs/HARDWARE-3D-ASSESSMENT.md` | PRIME status updated | ✅ |
| `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md` | Implementation status updated | ✅ |
## Implementation Status (2026-04-16)
| Step | Status | Deliverable |
|------|--------|-------------|
| 1. Delete dead dmabuf.rs | ✅ Done | File removed |
| 2. PRIME export/import in scheme | ✅ Done | DmaBuf nodes, export refcounting, mmap_prep, open/close/fpath |
| 3. Reference counting for shared GEM | ✅ Done | gem_export_refs, bump/drop, gem_can_close, maybe_close_gem |
| 4. Two-process reproducer | ✅ Recipe created | `local/recipes/tests/redox-drm-prime-test/` (runtime validation pending) |
| 5. libdrm Redox dispatch | ✅ Done | __redox__ wrappers in drmPrimeHandleToFD and drmPrimeFDToHandle |
| 6a. Mesa winsys scaffolding | ✅ Done | `src/gallium/winsys/redox/drm/` (4 files, compiles but does not render) |
| 6b. Mesa runtime buffer sharing | ⏳ Blocked | Requires GPU command submission (not yet implemented) |
**Stale token cleanup**: All GEM destruction paths now prune `prime_exports`. Central cleanup
in `maybe_close_gem()`, explicit cleanup in `GEM_CLOSE`/`DESTROY_DUMB`, liveness checks in
`PRIME_FD_TO_HANDLE` and `open("dmabuf/{token}")` that remove stale tokens on failure.
Verified by Oracle across 8 rounds.
**Protocol note**: PRIME uses opaque export tokens. PRIME_HANDLE_TO_FD returns a non-guessable
token stored in `prime_exports`. The client opens `/scheme/drm/card0/dmabuf/{token}`
to get a real scheme fd. `redox_fpath()` on that fd reveals the token. PRIME_FD_TO_HANDLE
accepts the export token and resolves it via `prime_exports`. Tokens are cleaned up when the
last export ref is dropped.
## Relationship to Other Plans
- `local/docs/HARDWARE-3D-ASSESSMENT.md` — broader hardware 3D status (command submission, fencing,
Mesa driver enablement). This document is the DMA-BUF-specific deep dive.
- `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` — canonical desktop path plan. DMA-BUF is a
prerequisite for the hardware-accelerated rendering phase.
- `local/docs/AMD-FIRST-INTEGRATION.md` — AMD-specific GPU details including GTT/VRAM programming.
- `docs/04-LINUX-DRIVER-COMPAT.md` — linux-kpi architecture reference for driver porting.
local/docs/HARDWARE-3D-ASSESSMENT.md
-171
View File
@@ -1,171 +0,0 @@
# Red Bear OS: Hardware-Accelerated 3D Assessment
**Date**: 2026-04-18
**Scope**: AMD + Intel GPU hardware OpenGL/Vulkan for KDE Plasma desktop
> **Planning authority note (2026-04-18):** this file is the current render-gap assessment and
> dependency reference. It is no longer the canonical GPU/DRM execution plan; use
> `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md` for sequencing and acceptance criteria.
## Bottom Line
PRIME/DMA-BUF cross-process buffer sharing is **now implemented** at the scheme level. GEM
allocation, PRIME export/import, and zero-copy mmap via FmapBorrowed all work through the
redox-drm scheme daemon and libdrm. The remaining gaps for hardware 3D are GPU command
submission (CS ioctl), GPU fence/signaling, and Mesa hardware Gallium driver enablement.
These are tracked separately in `local/docs/DMA-BUF-IMPROVEMENT-PLAN.md`.
## Capability Stack
```
Application (KDE Plasma / Qt6 / Wayland compositor)
↓
EGL / GBM / Wayland protocol
↓
Mesa (Gallium state tracker → hardware driver) ← ONLY swrast (CPU), Redox winsys scaffolding exists
↓
libdrm (userspace DRM wrapper) ← __redox__ PRIME dispatch ✅, opens /scheme/drm
↓
DRM scheme ioctls (GEM, PRIME, render) ← GEM ✅, PRIME ✅ (DmaBuf nodes), bounded private CS surface ✅, real render path ❌
↓
redox-drm (userspace DRM/KMS daemon) ← display ✅, buffer sharing ✅, render ❌
↓
Kernel (FmapBorrowed, sendfd, GPU interrupts) ← buffer sharing ✅, GPU fences ❌
↓
GPU hardware (AMD RDNA / Intel Gen)
```
## Layer-by-Layer Status
### 1. GPU Hardware Drivers (redox-drm + amdgpu + linux-kpi)
| Component | Status | Lines | What's Implemented |
|-----------|--------|-------|-------------------|
| DRM/KMS modesetting | ✅ Code complete | ~500 | 16 KMS ioctls, CRTC/connector/encoder/plane |
| AMD display backend (bounded retained path) | ✅ Builds | ~2 C glue files + Rust FFI surface | Red Bear display glue (`amdgpu_redox_main.c`, `redox_stubs.c`) plus the Rust FFI consumer build; imported Linux AMD DC/TTM/core remain builds and included in redbear-full (2026-04-29) |
| Intel Display Driver | ✅ Compiles | ~800 | Display pipe, GGTT, forcewake |
| GEM buffer management | ✅ Full | ~350 | create/close/mmap with DmaBuffer |
| GEM scheme ioctls | ✅ Wired | ~100 | GEM_CREATE, GEM_CLOSE, GEM_MMAP |
| PRIME scheme ioctls | ✅ Implemented | ~120 | PRIME_HANDLE_TO_FD + PRIME_FD_TO_HANDLE via DmaBuf nodes + export refcounting |
| libdrm PRIME dispatch | ✅ Implemented | ~30 | __redox__ wrappers: open dmabuf path + fpath-based GEM handle extraction |
| Mesa Redox winsys | 🚧 Scaffolding | ~4 files | Directory structure + stubs in src/gallium/winsys/redox/drm/ |
| Render command submission | ⚠️ Bounded shared surface only | small shared slice | private CS contract exists, but no vendor-usable render ioctl or ring programming |
| GPU context management | ❌ Missing | 0 | No context create/destroy |
| Fence/sync objects | ❌ Missing | 0 | No shared backend-complete GPU fence signaling |
| AMD ring buffer | ⚠️ Partial | ~100 | Page flip only, no general command submission |
### 2. Mesa Build Configuration
| Setting | Current Value | Needed for HW 3D |
|---------|--------------|-------------------|
| `gallium-drivers` | `swrast` | `swrast,radeonsi` (AMD) or `swrast,iris` (Intel) |
| `vulkan-drivers` | `swrast` | `swrast,amd` (RADV) or `swrast,intel` (ANV) |
| `platforms` | `redox` | `redox` (same) |
| EGL | enabled | enabled (same) |
| GBM | enabled | enabled (same) |
| `gallium-winsys` | none (swrast doesn't need one) | New Redox winsys for radeonsi/iris |
| `egl/platform_redox.c` | 540 lines, legacy display-backed | Needs DRM backend for HW buffers |
### 3. Kernel Infrastructure
| Feature | Status | Impact |
|---------|--------|--------|
| PCI enumeration | ✅ | GPU devices discovered |
| Memory scheme (phys mmap) | ✅ | GPU register access works |
| IRQ scheme (MSI-X) | ✅ | GPU interrupts can be delivered |
| DMA-BUF fd passing | ✅ Scheme-level | FmapBorrowed + sendfd + DmaBuf nodes enable zero-copy cross-process sharing |
| GPU fence/wait | ❌ | No shared backend-complete GPU completion signaling |
| IOMMU/GPU page tables for imports | ❌ | Imported buffers can't be mapped into GPU GTT |
## The Render Path Gap
For hardware OpenGL, the data path is:
```
Mesa Gallium (radeonsi)
→ libdrm open("drm:card0")
→ DRM_IOCTL_GEM_CREATE (allocate GPU buffer) ← EXISTS
→ DRM_IOCTL_PRIME_HANDLE_TO_FD (export for sharing) ← ✅ IMPLEMENTED (DmaBuf node + scheme fd)
→ bounded private CS submit surface ← EXISTS, but not a real vendor render path
→ DRM_IOCTL_AMDGPU_CS (submit commands to GPU) ← DOES NOT EXIST
→ fence wait (GPU completion) ← DOES NOT EXIST
→ present via KMS (PAGE_FLIP) ← EXISTS
```
Steps 1-2 now have full scheme ioctl support with cross-process buffer sharing via DmaBuf scheme
nodes, sendfd, and FmapBorrowed. There is now also a bounded private CS contract used to harden
shared DRM semantics, but steps 3-4 (real vendor command submission, fencing) remain the critical
gaps. The shared-core path now also applies explicit allocation caps for GEM and dumb-buffer
creation. The buffer sharing foundation is in place — compositors and clients can share GPU buffers
zero-copy. PRIME export now uses opaque non-guessable tokens rather than synthetic fd numbers.
The missing piece is still GPU command submission for actual rendering.
## What Was Implemented
| Change | Before | After |
|--------|--------|-------|
| `DRM_IOCTL_GEM_CREATE` | Not in scheme | Full ioctl handler: allocate GEM buffer, track ownership |
| `DRM_IOCTL_GEM_CLOSE` | Not in scheme | Full ioctl handler with ownership check |
| `DRM_IOCTL_GEM_MMAP` | Not in scheme | Full ioctl handler: return virtual address |
| `DRM_IOCTL_PRIME_HANDLE_TO_FD` | EOPNOTSUPP | Full implementation: opaque export tokens, prime_exports map, dmabuf fd creation |
| `DRM_IOCTL_PRIME_FD_TO_HANDLE` | EOPNOTSUPP | Full implementation: accepts export token (from redox_fpath), resolves via prime_exports |
| `libdrm __redox__ PRIME` | Not present | drmPrimeHandleToFD opens dmabuf path via export token; drmPrimeFDToHandle extracts token via redox_fpath |
| `NodeKind::DmaBuf` | Not present | DmaBuf node with mmap_prep returning GEM virtual address (enables FmapBorrowed) |
| `gem_export_refs` tracking | Not present | BTreeMap refcount for shared GEM objects, prevents premature gem_close |
| Mesa winsys scaffolding | Not present | src/gallium/winsys/redox/drm/ stub directory structure |
## What Remains (Ordered by Dependency)
### Tier 1: Can be done without kernel changes
1. **Mesa Gallium hardware driver enablement** — Change recipe from `-Dgallium-drivers=swrast` to
include `radeonsi` or `iris`. This will fail to build without a winsys, but the attempt reveals
the exact Mesa-side gaps.
2. **Redox Mesa winsys** — Scaffolding exists at `src/gallium/winsys/redox/drm/` (compile-time
stubs). Needs real implementation of buffer allocation, PRIME export/import, and mmap.
PRIME ioctls are now implemented in redox-drm and libdrm has `__redox__` dispatch.
3. **libdrm Redox backend** — libdrm already has `__redox__` conditional handling, opens
`/scheme/drm`, and dispatches PRIME ioctls via `redox_fpath()` and dmabuf path opening.
The remaining gap is GPU-family-specific command submission ioctls.
### Tier 2: Requires kernel work
4. **GPU command submission** — The amdgpu and Intel drivers need ring buffer programming for
3D command submission, not just page flip. This is GPU-family-specific:
- AMD: GFX ring, compute ring, SDMA ring
- Intel: render ring, blitter ring
6. **GPU fence/signaling** — After submitting commands, the kernel needs to signal completion
back to userspace. This requires IRQ handling that maps GPU interrupts to fence objects.
### Tier 3: Requires significant new code
7. **GTT/PPGTT population for imported buffers** — When Mesa imports a DMA-BUF into the GPU,
the buffer's physical pages must be mapped into the GPU's address space. Currently only
internally-allocated GEM objects get GTT mappings.
8. **Mesa EGL platform extension** — `platform_redox.c` currently uses the legacy display backend for buffer
management. It needs an alternative path that uses DRM GEM for hardware-accelerated
surfaces.
## Estimated Effort (2 developers)
| Tier | Duration | Deliverable |
|------|----------|-------------|
| Tier 1 (userspace) | 8-16 weeks | Mesa builds with radeonsi, winsys talks to DRM scheme |
| Tier 2 (kernel/driver) | 12-20 weeks | GPU command submission, fences, VRAM placement |
| Tier 3 (integration) | 6-12 weeks | Hardware-accelerated OpenGL applications |
| **Total** | **26-48 weeks** | **Hardware 3D on AMD** |
Intel (iris) is expected to be faster than AMD (radeonsi is ~6M lines vs iris ~400k) but both are
equal-priority Red Bear OS targets. The order of enablement is driven by driver complexity, not
platform priority.
## Relationship to Other Plans
- `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` — Phase 5 covers hardware GPU enablement
- `local/docs/AMD-FIRST-INTEGRATION.md` — AMD-specific GPU driver details
- `local/docs/AMDGPU-DC-COMPILE-TRIAGE-PLAN.md` — AMD DC compile-triage and bounded source-set strategy
- `docs/04-LINUX-DRIVER-COMPAT.md` — linux-kpi architecture reference
local/docs/INPUT-SCHEME-ENHANCEMENT.md
-547
View File
@@ -1,547 +0,0 @@
# INPUTD SCHEME API ENHANCEMENT DESIGN
**Target**: `recipes/core/base/source/drivers/inputd`
**Scope**: Userspace-only `inputd` scheme enhancement
**Date**: 2026-04-13
## 1. Goal
Enhance `inputd` so it can do all of the following without breaking any existing callers:
1. Let producers register under stable names such as `ps2-keyboard`, `ps2-mouse`, or `usb-hid0`.
2. Expose per-device consumer streams so services such as `evdevd` can subscribe to one device only.
3. Publish hotplug notifications for device add/remove.
4. Expose currently registered devices through the scheme root directory.
This is an **additive** design. Existing paths, existing event payloads, existing VT behavior, and existing display/control behavior must continue to work unchanged.
## 2. Current Implementation Summary
The current `inputd` implementation in `recipes/core/base/source/drivers/inputd/src/main.rs` has these important properties:
- `Handle` only supports `Producer`, `Consumer`, `Display`, `Control`, and `SchemeRoot`.
- `openat()` only recognizes `producer`, `consumer`, `consumer_bootlog`, `handle`, `handle_early`, and `control`.
- All producers write anonymous `orbclient::Event` bytes into the same `Handle::Producer` path.
- Legacy consumers are per-VT handles. `write()` only delivers input bytes to the **active VT** consumer set.
- `SchemeRoot` exists, but it is not a real directory yet: it does not enumerate entries.
- `lib.rs` only exposes `ProducerHandle`, `ConsumerHandle`, `DisplayHandle`, and `ControlHandle`.
Current callers after migration:
- `ps2d` opens two `InputProducer` instances (`ps2-keyboard`, `ps2-mouse`) with legacy fallback, routing keyboard scancodes to the keyboard producer and mouse events to the mouse producer.
- `usbhidd` opens one `InputProducer` per interface instance (`usb-{port}-if{n}`) with legacy fallback.
- local `evdevd` reads `/scheme/input/consumer`, receives anonymous mixed `orbclient::Event` values, and manually translates them (not yet migrated to per-device streams).
## 3. Design Principles
1. **Keep legacy behavior intact**: `/scheme/input/producer` and `/scheme/input/consumer` must keep working exactly as they do today.
2. **Do not change event payloads**: device-specific streams still carry serialized `orbclient::Event` values.
3. **Keep all logic in userspace**: no kernel changes, no new kernel scheme semantics.
4. **Make enumeration path-driven**: device names are visible as entries below `/scheme/input/`.
5. **Use explicit hotplug events**: device discovery and liveness must not depend on polling failed opens.
## 4. Scheme Path Layout
The enhanced namespace is:
```text
/scheme/input/ — SchemeRoot (directory listing)
/scheme/input/producer — Legacy producer (unchanged)
/scheme/input/producer/{name} — Named producer: ps2-keyboard, ps2-mouse, usb-hid0
/scheme/input/consumer — Legacy consumer (unchanged)
/scheme/input/{device_name} — Per-device consumer: reads events from one named producer
/scheme/input/events — Hotplug event stream
/scheme/input/handle/{display} — Display handle (unchanged)
/scheme/input/control — Control commands (unchanged)
```
Legacy-only paths that must remain valid even though they are not part of the new API surface:
```text
/scheme/input/consumer_bootlog — Existing bootlog VT consumer
/scheme/input/handle_early/{display} — Existing early framebuffer handoff path
```
### 4.1 Root Directory Listing
`SchemeRoot` should become a real directory endpoint backed by `getdents`, not by overloading `read()`.
The root listing should expose:
- static entries: `producer`, `consumer`, `consumer_bootlog`, `events`, `handle`, `handle_early`, `control`
- one dynamic entry per registered device name from `devices`
That keeps the namespace honest while still allowing device enumeration from `/scheme/input/`.
`InputDeviceLister` in `lib.rs` should filter out the reserved static names and return only dynamic device entries.
## 5. Handle Model
The `Handle` enum in `main.rs` should become:
```rust
enum Handle {
Producer,
NamedProducer {
name: String,
},
Consumer {
events: EventFlags,
pending: Vec<u8>,
needs_handoff: bool,
notified: bool,
vt: usize,
},
DeviceConsumer {
device_name: String,
events: EventFlags,
pending: Vec<u8>,
notified: bool,
},
HotplugEvents {
events: EventFlags,
pending: Vec<u8>,
notified: bool,
},
Display {
events: EventFlags,
pending: Vec<VtEvent>,
notified: bool,
device: String,
is_earlyfb: bool,
},
Control,
SchemeRoot,
}
```
Notes:
- `Producer` remains the legacy anonymous producer path.
- `NamedProducer` only needs the registered name. Device ID lookup stays in shared scheme state.
- `DeviceConsumer` is byte-oriented like the legacy consumer, but without VT or handoff state.
- `HotplugEvents` stores serialized variable-length hotplug records in `pending`.
- `SchemeRoot` remains a dedicated handle variant, but now supports directory enumeration.
## 6. Scheme Open Semantics
`openat()` should parse paths as follows:
### 6.1 Existing Paths
- `producer` with no child component → `Handle::Producer`
- `consumer` → current VT consumer allocation logic
- `consumer_bootlog` → current VT 1 logic
- `handle/{display}` → unchanged
- `handle_early/{display}` → unchanged
- `control` → unchanged
### 6.2 New Paths
- `producer/{name}` → `Handle::NamedProducer { name }`
- `events` → `Handle::HotplugEvents { ... }`
- any other top-level non-reserved path component → `Handle::DeviceConsumer { device_name, ... }`
### 6.3 Name Validation
Named producer registration must reject:
- empty names
- names containing `/`
- reserved names: `producer`, `consumer`, `consumer_bootlog`, `events`, `handle`, `handle_early`, `control`
- duplicate live names already present in `devices`
Recommended error behavior:
- invalid name → `EINVAL`
- duplicate name → `EEXIST`
- open of `/scheme/input/{device_name}` for a currently unknown device → `ENOENT`
## 7. State Management
`InputScheme` should add:
```rust
devices: BTreeMap<String, u32>,
next_device_id: AtomicUsize,
```
Purpose:
- `devices` maps device name → current device ID
- `next_device_id` allocates monotonically increasing IDs
Behavior:
1. When `NamedProducer` opens successfully:
- allocate `device_id = next_device_id.fetch_add(1, Ordering::SeqCst) as u32`
- insert `devices.insert(name.clone(), device_id)`
- serialize a `DEVICE_ADD` hotplug message
- append it to every `Handle::HotplugEvents.pending`
- set `notified = false` on those hotplug handles
- set `has_new_events = true`
2. When `NamedProducer` closes:
- remove the entry from `devices`
- serialize a `DEVICE_REMOVE` hotplug message with the removed ID and name
- append it to every `Handle::HotplugEvents.pending`
- set `notified = false`
- set `has_new_events = true`
3. Device IDs are never reused. If `ps2-keyboard` disappears and later comes back, it gets a new `device_id`.
No additional kernel state is required. This is ordinary daemon-side bookkeeping.
## 8. Event Routing Logic
The existing preprocessing path in `write()` must remain in place:
- special Super+Fn VT switching behavior stays in `inputd`
- keymap translation still happens in `inputd`
- the emitted payload remains serialized `orbclient::Event`
After that preprocessing step, routing changes as follows.
### 8.1 Legacy Producer
Input written to `/scheme/input/producer` follows the current legacy route:
- deliver to the existing legacy consumer path
- preserve current active-VT behavior
- do **not** deliver to any `DeviceConsumer`
- do **not** generate hotplug events
### 8.2 Named Producer
Input written to `/scheme/input/producer/{name}` must be fanned out to:
1. the matching `DeviceConsumer` handles where `device_name == name`
2. the existing legacy consumer path used by older display/input clients
That means named producers are **supersets** of legacy routing, not replacements.
### 8.3 Device Consumer
`/scheme/input/{device_name}` only receives events from the named producer with the exact same name.
It must never receive:
- anonymous legacy producer traffic
- events from other named producers
- display or control events
### 8.4 Routing Sketch
```text
legacy producer write
-> existing input normalization
-> legacy VT consumer fan-out only
named producer write(name)
-> existing input normalization
-> device consumers for name
-> legacy VT consumer fan-out
```
Implementation-wise, the simplest approach is:
1. detect whether the writer is `Producer` or `NamedProducer { name }`
2. run the existing event transformation code once
3. serialize transformed `Event` values once
4. if named, append to matching `DeviceConsumer.pending`
5. append to the legacy consumer path using the current active-VT logic
6. clear `notified` on affected readers and set `has_new_events = true`
## 9. Hotplug Event Stream
`/scheme/input/events` is a read-only stream of variable-length hotplug records.
### 9.1 Binary Format
```rust
#[repr(C)]
struct InputHotplugEvent {
kind: u32, // 1 = DEVICE_ADD, 2 = DEVICE_REMOVE
device_id: u32, // Unique device identifier
name_len: u32, // Length of device name
_reserved: u32, // Future use
}
// Followed by name_len bytes of UTF-8 device name
```
Constants:
```rust
const DEVICE_ADD: u32 = 1;
const DEVICE_REMOVE: u32 = 2;
```
### 9.2 Stream Semantics
- The stream is append-only and ordered by daemon observation.
- Each record is serialized as header bytes followed by UTF-8 name bytes.
- `read()` drains raw bytes from `pending`.
- Because records are variable-length, callers must handle partial reads.
- `HotplugHandle` in `lib.rs` should hide this by buffering partial bytes until one full record is available.
### 9.3 Notification Model
`Handle::HotplugEvents` participates in `fevent(EVENT_READ)` exactly like other readable handles:
- when at least one serialized hotplug record is pending and the handle is subscribed to `EVENT_READ`, post a read event
- after a successful read drains the buffer, notification becomes edge-triggered again
## 10. Scheme Root Enumeration
Enumeration should be implemented with `getdents()` on `Handle::SchemeRoot`.
Recommended behavior:
- `scheme_root()` still creates a `Handle::SchemeRoot`
- `getdents()` emits static entries plus one entry per `devices` key
- `read()` on `SchemeRoot` stays invalid (`EBADF` or `EISDIR` are both acceptable if applied consistently)
- `openat()` continues to require a valid `SchemeRoot` dirfd
Example visible entries after `ps2d` registers keyboard and mouse:
```text
producer
consumer
consumer_bootlog
events
handle
handle_early
control
ps2-keyboard
ps2-mouse
```
This gives normal filesystem-style discovery while keeping old endpoints visible.
## 11. `lib.rs` Public API Changes
The public API should be extended, not replaced.
### 11.1 Existing Types Stay
- `ProducerHandle`
- `ConsumerHandle`
- `DisplayHandle`
- `ControlHandle`
Their existing constructors and behavior remain unchanged.
### 11.2 New Types
```rust
pub struct NamedProducerHandle(File);
pub struct DeviceConsumerHandle(File);
pub struct HotplugHandle {
file: File,
partial: Vec<u8>,
}
#[derive(Debug, Clone)]
#[repr(C)]
pub struct HotplugEventHeader {
pub kind: u32,
pub device_id: u32,
pub name_len: u32,
pub reserved: u32,
}
#[derive(Debug, Clone)]
pub struct HotplugEvent {
pub kind: u32,
pub device_id: u32,
pub name: String,
}
pub struct InputDeviceLister;
```
### 11.3 Constructors
```rust
impl NamedProducerHandle {
pub fn new(name: &str) -> io::Result<Self>;
}
impl DeviceConsumerHandle {
pub fn new(device_name: &str) -> io::Result<Self>;
}
impl HotplugHandle {
pub fn new() -> io::Result<Self>;
}
```
Path mapping:
- `NamedProducerHandle::new("ps2-keyboard")` → `/scheme/input/producer/ps2-keyboard`
- `DeviceConsumerHandle::new("ps2-keyboard")` → `/scheme/input/ps2-keyboard`
- `HotplugHandle::new()` → `/scheme/input/events`
### 11.4 Read/Write Shape
Recommended API shape:
```rust
impl NamedProducerHandle {
pub fn write_event(&mut self, event: orbclient::Event) -> io::Result<()>;
}
pub enum DeviceConsumerHandleEvent<'a> {
Events(&'a [Event]),
}
impl DeviceConsumerHandle {
pub fn event_handle(&self) -> BorrowedFd<'_>;
pub fn read_events<'a>(&self, events: &'a mut [Event])
-> io::Result<DeviceConsumerHandleEvent<'a>>;
}
impl HotplugHandle {
pub fn event_handle(&self) -> BorrowedFd<'_>;
pub fn read_event(&mut self) -> io::Result<Option<HotplugEvent>>;
}
```
`DeviceConsumerHandle` deliberately mirrors `ConsumerHandle`, but it does not need `Handoff` support because VT display handoff is unrelated to per-device streams.
### 11.5 Device Enumeration Helper
`InputDeviceLister` should provide a safe wrapper around scheme-root directory reads, for example:
```rust
impl InputDeviceLister {
pub fn list() -> io::Result<Vec<String>>;
}
```
Behavior:
- read `/scheme/input/` as a directory
- drop reserved static entries
- return only currently registered device names
This keeps callers out of scheme-internal filtering logic.
## 12. Producer Lifecycle and Consumer Behavior
### 12.1 Named Producer Registration
Opening `/scheme/input/producer/{name}` is both:
- creation of a producer handle
- registration of `{name}` as a live device
Closing the fd unregisters the device.
This matches current scheme style well because `inputd` already uses `on_close()` to clean up VT consumers.
### 12.2 Device Consumer Lifetime
Per-device consumer handles are name-based subscriptions.
- open succeeds only while the device name is currently registered
- once open, the handle remains attached to that name
- if the producer disappears, no more events arrive for that handle
- if the same name is registered again later, the handle resumes receiving events for that name
- the hotplug stream is how clients notice that the underlying producer instance changed
This keeps `DeviceConsumer` simple and avoids introducing a second handle teardown protocol.
## 13. Migration Path
### 13.1 `ps2d` — MIGRATED
`ps2d` now uses two `InputProducer` instances with named-first, legacy-fallback strategy:
1. Try `InputProducer::new_named_or_fallback("ps2-keyboard")` → falls back to legacy on error
2. Try `InputProducer::new_named_or_fallback("ps2-mouse")` → falls back to legacy on error
3. `Ps2d` struct holds `keyboard_input: InputProducer` + `mouse_input: InputProducer`
Routing:
- keyboard scancodes → `self.keyboard_input`
- mouse move / absolute move / button / scroll events → `self.mouse_input`
This preserves compatibility with old `inputd` while enabling per-device consumers on new `inputd`.
### 13.2 `evdevd`
Once the scheme exists, local `evdevd` can move from `/scheme/input/consumer` to:
- `InputDeviceLister::list()` to discover devices
- `DeviceConsumerHandle::new(name)` for device-local streams
- `HotplugHandle::new()` to watch add/remove
It can keep the legacy consumer path as a fallback for older systems.
### 13.3 `usbhidd` — MIGRATED
`usbhidd` now uses one `InputProducer` per interface instance with named-first, legacy-fallback strategy:
1. Opens `InputProducer::new_named_or_fallback(&format!("usb-{}-if{}", port, interface_num))`
2. Falls back to legacy on error
3. All event writes go through the same `write_event()` method
Producer names: `usb-{port}-if{interface_num}` (e.g., `usb-1-if0`, `usb-1-if1`).
## 14. Backward Compatibility Requirements
All of the following must continue to work unchanged:
- `/scheme/input/producer`
- `/scheme/input/consumer`
- `/scheme/input/consumer_bootlog`
- `/scheme/input/handle/{display}`
- `/scheme/input/handle_early/{display}`
- `/scheme/input/control`
- current `ProducerHandle`, `ConsumerHandle`, `DisplayHandle`, and `ControlHandle` APIs
- current active-VT routing and graphics handoff behavior
Compatibility rules:
1. Old producers still emit anonymous events into the legacy stream.
2. Old consumers still receive the same event format and VT behavior.
3. New named producers additionally feed the legacy stream, so old consumers continue to see those events.
4. No caller is forced to understand hotplug or enumeration.
## 15. Non-Goals
This design does **not** include:
- capability discovery (`keyboard` vs `mouse` metadata)
- kernel support or syscall ABI changes
- replacing `orbclient::Event` with a new event format
- changing VT ownership, display handoff, or control command semantics
- automatic migration of existing daemons
## 16. Implementation Checklist
Another developer implementing this design should be able to proceed in this order:
1. extend `Handle` and `InputScheme` state ✅
2. teach `openat()` to parse `producer/{name}`, `events`, and dynamic device names ✅
3. add root `getdents()` support for `SchemeRoot` ✅
4. refactor `write()` so producer type is detected before routing ✅
5. fan out named-producer events to matching `DeviceConsumer` handles and the existing legacy path ✅
6. add hotplug queue serialization helpers ✅
7. extend `fevent()` and daemon notification loop for `DeviceConsumer` and `HotplugEvents` ✅
8. add cleanup in `on_close()` for `NamedProducer` ✅
9. extend `lib.rs` with the new handle types and directory lister ✅
10. migrate `ps2d` with a named-producer-first, legacy-fallback strategy ✅
11. migrate `usbhidd` with a named-producer-first, legacy-fallback strategy ✅
## 17. Final Outcome
After this enhancement:
- Legacy consumers continue to work as-is.
- `ps2d` and future drivers can publish stable device names.
- `evdevd` and similar services can subscribe to exactly one device stream.
- userspace can enumerate live input devices and react to hotplug events.
That solves the current anonymity problem without changing the kernel or breaking the existing Redox input stack.
local/docs/LINUX-BORROWING-RUST-IMPLEMENTATION-PLAN.md
-494
View File
@@ -1,494 +0,0 @@
# Linux Borrowing and Rust Implementation Plan for Red Bear OS
**Date:** 2026-04-18
**Status:** Planning authority for Linux-derived borrowing boundaries and Rust rewrite guidance across low-level subsystem work. PCI/IRQ rollout authority lives in `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`.
**Scope:** Hardware enablement, ACPI including suspend/resume, low-level startup/init, PCI, IRQ/MSI/MSI-X, PS/2 init, IOMMU, USB/xHCI/storage, bounded Wi-Fi transport reuse, and selective GPU/DRM orchestration reuse
## Intent
Which Linux kernel source and Linux documentation already present in this repo should be used as donor material for Red Bear OS, what should be rewritten into Rust, what should remain reference-only, and where should that logic live in Red Bear's architecture?
This plan is intentionally **Red Bear-native**. It does **not** propose importing Linux subsystem architecture into Red Bear.
## Current implementation status snapshot (2026-04-18)
The software-only, bounded slices from this plan that are now implemented in code are:
- **Phase A — PCI / IRQ substrate**
- bounded shared substrate slices landed in code (`redox-driver-sys` capability-chain parsing,
interrupt-support summary, and early `pcid` convergence)
- the **canonical execution order, current robustness judgment, and remaining implementation work**
for PCI/IRQ now live in `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
- **Phase B — ACPI / IOMMU groundwork**
- `acpid` now carries an explicit userspace sleep-target model naming `S1` / `S3` / `S4` / `S5`
- only `_S5` soft-off is materially wired today; non-`S5` targets remain groundwork-only
- `iommu` now detects kernel ACPI `DMAR` presence as a convergence seam, but Intel VT-d runtime ownership is not yet cleanly closed outside `acpid`
- **Phase C — PS/2 / USB / storage**
- `ps2d` now flushes stale controller output during probe and around core init/self-test
- `xhcid` now tracks active alternate settings and resolves endpoint descriptors through that map
- `usbscsid` now has a bounded `SYNCHRONIZE CACHE(10/16)` heuristic behind `needs_sync_cache`
- **Phase D — Wi-Fi / DRM shared-core**
- `redbear-wifictl` transport probing now uses the shared PCI parser and interrupt-support summary
- `redox-drm` now exposes queued shared hotplug/vblank events through a real scheme `EVENT_READ` surface
The work that still remains is the larger **vendor/backend maturation and hardware-validation** side:
- full ACPI sleep/resume implementation beyond groundwork
- full Intel VT-d runtime support beyond DMAR ownership discovery
- deeper PCI / `pcid` convergence on shared helpers
- broader PS/2 resume/wake policy
- broader USB architecture/runtime maturation beyond the bounded helper slices already implemented
- deeper Wi-Fi transport/helper extraction beyond probing
- Intel and AMD DRM backend maturation and real hardware validation
This document should therefore be read as:
- **implemented now** for the bounded shared-core and software-only slices listed above
- **still in progress** for backend maturation and hardware-backed acceptance phases
## Hard rules
1. **Linux suspend/resume is reference-only.** Red Bear should study Linux ordering and edge cases, but implement its own suspend/resume support in the Red Bear architecture.
2. **`linux-kpi` is GPU and Wi-Fi only.** It is not a general solution for ACPI, USB, input, startup, or general platform ownership.
3. **Do not copy Linux subsystem structure blindly.** Use Linux as an algorithm, quirk, parser, and sequencing donor; implement the resulting behavior in Red Bear’s own kernel/scheme/userspace-daemon model.
4. **Keep Red Bear ownership boundaries intact.** Kernel remains minimal; runtime/controller policy stays in userspace daemons; reusable low-level helpers converge into shared Rust crates.
5. **Respect provenance and license constraints.** Treat Linux driver code as reference/reverse-engineering input unless a bounded donor island already exists in-tree. Prefer datasheets when available.
## Repo-grounded evidence base
### Actual Linux-derived material in this repo
- Imported AMDGPU/DC tree: `local/recipes/gpu/amdgpu-source/`
- Bounded Intel Wi-Fi transport donor: `local/recipes/drivers/redbear-iwlwifi/source/src/linux_port.c`
- Linux compatibility layer for bounded donor ports: `local/recipes/drivers/linux-kpi/`
- Red Bear-native low-level substrate: `local/recipes/drivers/redox-driver-sys/`
- Linux-mined quirk system and tables:
- `local/recipes/drivers/redox-driver-sys/source/src/quirks/*`
- `local/docs/QUIRKS-SYSTEM.md`
- Linux source cache used as donor/reference material:
- `build/linux-kernel-cache/linux-7.0/`
### Linux source files directly relevant to this plan
- ACPI sleep and PM ordering:
- `build/linux-kernel-cache/linux-7.0/drivers/acpi/sleep.c`
- PS/2 / i8042:
- `build/linux-kernel-cache/linux-7.0/drivers/input/serio/i8042.c`
- PCI / quirks / MSI:
- `build/linux-kernel-cache/linux-7.0/drivers/pci/probe.c`
- `build/linux-kernel-cache/linux-7.0/drivers/pci/quirks.c`
- `build/linux-kernel-cache/linux-7.0/drivers/pci/msi/msi.c`
- USB / xHCI / hub:
- `build/linux-kernel-cache/linux-7.0/drivers/usb/host/xhci-pci.c`
- `build/linux-kernel-cache/linux-7.0/drivers/usb/core/hub.c`
- Storage heuristics:
- `build/linux-kernel-cache/linux-7.0/drivers/scsi/sd.c`
- IOMMU:
- `build/linux-kernel-cache/linux-7.0/drivers/iommu/amd/init.c`
- `build/linux-kernel-cache/linux-7.0/drivers/iommu/intel/iommu.c`
- GPU / DRM:
- `build/linux-kernel-cache/linux-7.0/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c`
- `build/linux-kernel-cache/linux-7.0/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c`
- Intel Wi-Fi transport:
- `build/linux-kernel-cache/linux-7.0/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c`
### Linux documentation directly relevant to this plan
- Power / suspend:
- `build/linux-kernel-cache/linux-7.0/Documentation/power/suspend-and-interrupts.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/power/s2ram.rst`
- PCI / interrupts:
- `build/linux-kernel-cache/linux-7.0/Documentation/PCI/msi-howto.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/PCI/boot-interrupts.rst`
- Input / PS/2 context:
- `build/linux-kernel-cache/linux-7.0/Documentation/input/input-programming.rst`
- ACPI:
- `build/linux-kernel-cache/linux-7.0/Documentation/driver-api/acpi/acpi-drivers.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/driver-api/acpi/scan_handlers.rst`
- USB:
- `build/linux-kernel-cache/linux-7.0/Documentation/driver-api/usb/writing_usb_driver.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/usb/mass-storage.rst`
- GPU / DRM:
- `build/linux-kernel-cache/linux-7.0/Documentation/gpu/drm-kms.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/gpu/drm-uapi.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/gpu/drm-internals.rst`
- Wi-Fi:
- `build/linux-kernel-cache/linux-7.0/Documentation/driver-api/80211/introduction.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/driver-api/80211/cfg80211.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/driver-api/80211/mac80211.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/driver-api/80211/mac80211-advanced.rst`
- `build/linux-kernel-cache/linux-7.0/Documentation/networking/napi.rst`
### Red Bear current-state and planning sources used
- `docs/04-LINUX-DRIVER-COMPAT.md`
- `local/docs/ACPI-IMPROVEMENT-PLAN.md`
- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
- `local/docs/USB-IMPLEMENTATION-PLAN.md`
- `local/docs/USB-VALIDATION-RUNBOOK.md`
- `local/docs/WIFI-IMPLEMENTATION-PLAN.md`
- `local/docs/QUIRKS-SYSTEM.md`
- `local/docs/IOMMU-SPEC-REFERENCE.md`
- `local/docs/DBUS-INTEGRATION-PLAN.md`
- `local/docs/DRM-MODERNIZATION-EXECUTION-PLAN.md`
- `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md`
---
# Part 1 — Comprehensive assessment
## 1. Red Bear ownership model that must be preserved
### Kernel-owned minimum platform baseline
Grounded in:
- `recipes/core/kernel/source/src/startup/mod.rs`
- `recipes/core/kernel/source/src/startup/memory.rs`
- `recipes/core/kernel/source/src/acpi/mod.rs`
- `recipes/core/kernel/source/src/scheme/serio.rs`
Kernel should keep only:
- boot memory/bootstrap
- early ACPI table discovery
- MADT / HPET / APIC / IRQ baseline
- race-critical `serio` byte queueing
### Userspace runtime/controller ownership
Grounded in:
- `recipes/core/base/source/drivers/hwd/src/main.rs`
- `recipes/core/base/source/drivers/hwd/src/backend/acpi.rs`
- `recipes/core/base/source/drivers/acpid/src/acpi.rs`
- `recipes/core/base/source/drivers/pcid/src/main.rs`
- `recipes/core/base/source/drivers/input/ps2d/src/controller.rs`
- `local/recipes/system/iommu/source/src/main.rs`
- `recipes/core/base/source/drivers/usb/xhcid/src/main.rs`
Userspace owns:
- ACPI runtime and AML policy (`acpid`)
- PCI enumeration and driver-facing interrupt policy (`pcid`)
- IOMMU runtime ownership (`iommu`)
- PS/2 controller state machine (`ps2d`)
- USB controller/runtime policy (`xhcid`, related daemons)
- session-facing power signals (`redbear-sessiond`)
- Wi-Fi control/runtime policy (`redbear-wifictl`, `redbear-netctl`)
### Shared Rust substrate
Grounded in:
- `local/recipes/drivers/redox-driver-sys/source/src/{pci,irq,dma}.rs`
- `local/recipes/drivers/redox-driver-sys/source/src/quirks/*`
Shared Rust should own:
- reusable PCI helpers
- MSI/MSI-X helpers
- DMA helpers
- quirk lookups
- future IVRS/DMAR helper modules
## 2. Actual startup / init ordering
### Strict chain
Grounded in:
- `recipes/core/base/source/drivers/hwd/src/backend/acpi.rs`
- `recipes/core/base/source/drivers/hwd/src/main.rs`
- `recipes/core/base/source/drivers/acpid/src/acpi.rs`
- `recipes/core/base/source/init.initfs.d/40_pcid.service`
- `recipes/core/base/source/init.initfs.d/41_acpid.service`
- `recipes/core/base/source/init.initfs.d/40_hwd.service`
- `recipes/core/base/source/init.initfs.d/40_pcid-spawner-initfs.service`
Strict order:
1. kernel bootstrap / memory / early ACPI / IRQ / serio baseline
2. userspace bootstrap
3. `pcid` starts in initfs (`40_pcid.service`)
4. `acpid` starts in initfs (`41_acpid.service`)
5. `hwd` starts (`40_hwd.service`) and probes only after `pcid` + `acpid`
6. `pcid-spawner` runs (`40_pcid-spawner-initfs.service`)
7. `acpid` waits for PCI registration before AML-symbol readiness
### Shared initfs target membership (not strict serialization)
Grounded in:
- `recipes/core/base/source/init.initfs.d/40_pcid.service`
- `recipes/core/base/source/init.initfs.d/40_hwd.service`
- `recipes/core/base/source/init.initfs.d/41_acpid.service`
- `recipes/core/base/source/init.initfs.d/40_pcid-spawner-initfs.service`
- `recipes/core/base/source/init.initfs.d/40_ps2d.service`
- `recipes/core/base/source/init.initfs.d/40_drivers.target`
- `recipes/core/base/source/init.initfs.d/10_inputd.service`
- `recipes/core/base/source/init.initfs.d/10_lived.service`
- `recipes/core/base/source/init.initfs.d/20_graphics.target`
Important nuance:
- `ps2d`, `pcid`, `acpid`, `hwd`, and `pcid-spawner-initfs` all participate in early initfs driver bring-up.
- They are grouped by `40_drivers.target`, but they are **not** one single strict serial chain.
## 3. What Linux material Red Bear should borrow into Rust
### Subsystem matrix
| Subsystem | Linux donor material | Rewrite into Rust | Keep reference-only | Red Bear owner |
|---|---|---|---|---|
| ACPI / suspend | `drivers/acpi/sleep.c`, `Documentation/power/*`, `Documentation/driver-api/acpi/*` | sleep sequencing helpers, AML/power orchestration helpers, wake-source modeling | Linux PM core, ACPI device-node driver ownership | `acpid`, `redbear-sessiond` |
| PCI | `drivers/pci/probe.c`, `drivers/pci/quirks.c`, `Documentation/PCI/*` | capability walkers, BAR/resource validation, fixup/quirk pass model | Linux PCI core ownership | `pcid`, `redox-driver-sys` |
| IRQ / MSI / MSI-X | `drivers/pci/msi/*`, PCI docs | interrupt mode selection, vector policy, masking/fallback helpers | Linux generic IRQ core | kernel `irq:`, `pcid`, `redox-driver-sys` |
| PS/2 / i8042 | `drivers/input/serio/i8042.c`, input docs | reset/resume policy, aux/mux quirks, recovery deltas only | Linux input core | `serio`, `ps2d` |
| IOMMU | `drivers/iommu/amd/init.c`, `drivers/iommu/intel/iommu.c` | IVRS/DMAR parsers, table encoders, pre-enabled translation handling | Linux iommu-core structure | `iommu`, shared Rust helpers |
| USB / xHCI | `drivers/usb/host/xhci-pci.c`, `drivers/usb/core/hub.c`, USB docs | quirk logic, suspend/resume sequencing, composite/interface correctness | Linux USB core / driver model | `xhcid`, `usbhubd`, `usbscsid` |
| USB storage | `drivers/scsi/sd.c`, `Documentation/usb/mass-storage.rst` | bounded cache/flush/capacity heuristics | broad Linux SCSI midlayer architecture | `usbscsid` |
| Wi-Fi | `iwlwifi` transport, 80211 docs, NAPI docs | selected queue/DMA/IRQ/timeout helper patterns only | cfg80211/mac80211/NAPI architecture | bounded donor transport + native `wifictl`/`netctl` |
| GPU / DRM | `amdgpu_device.c`, `amdgpu_dm.c`, DRM docs, imported AMDGPU tree | orchestration, phase sequencing, quirk policy, selected shared helpers later | full DRM/AMDGPU runtime architecture | `redox-drm`, bounded vendor backends |
## 4. What Linux material must remain reference-only
- Linux PM core
- Linux driver core
- Linux USB core
- Linux input core
- Linux wireless subsystem architecture (`cfg80211`, `mac80211`, NAPI ownership model)
- Linux tasklet/workqueue ownership model
- Full AMDGPU runtime architecture
Reason: all of those conflict with the ownership rules that Red Bear already implements and should keep.
## 5. What Red Bear still materially needs
- ACPI sleep beyond `_S5`
- clean Intel VT-d / DMAR runtime ownership outside `acpid`
- better PCI host bridge / interrupt-link handling
- quirk convergence in `redox-driver-sys`
- USB composite/interface correctness
- hardware validation before deeper GPU/Wi-Fi extraction
---
# Part 2 — How to implement it in Red Bear OS
## 1. Placement rules
### Kernel
Keep only:
- bootstrap
- memory initialization
- early ACPI table discovery
- APIC/HPET/IRQ baseline
- race-critical `serio`
### Userspace daemons
- `acpid`: ACPI runtime policy, AML, sleep orchestration
- `pcid`: PCI enumeration/config/capability export/interrupt mode policy
- `iommu`: AMD-Vi / VT-d runtime ownership
- `ps2d`: PS/2 controller init/reset/resume/data path
- `xhcid`, `usbhubd`, `usbscsid`: controller/hub/storage runtime logic
- `redbear-sessiond`: D-Bus/session-facing sleep/shutdown bridge
- `redbear-wifictl`, `redbear-netctl`: native Wi-Fi control plane
### Shared Rust crates
- `redox-driver-sys`: canonical home for reusable PCI/IRQ/DMA/quirk/IOMMU helpers
- `linux-kpi`: bounded donor bridge for GPU/Wi-Fi only
## 2. Implementation order
For current execution order, priority ranking, and acceptance language:
- use `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` for PCI / IRQ / low-level
controller work,
- use `local/docs/ACPI-IMPROVEMENT-PLAN.md` for ACPI ownership/robustness/sleep work,
- use `local/docs/USB-IMPLEMENTATION-PLAN.md` for USB maturity,
- and use the Wi-Fi / DRM plans for those later subsystem-specific phases.
This file should keep the **borrowing and rewrite policy** for those phases, not act as a competing
execution roadmap.
## 3. Work package backlog
### Phase A — PCI / IRQ / quirk substrate
For Phase A execution detail, file targets, acceptance criteria, and validation language, use the
canonical PCI/IRQ plan:
- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
This document keeps only the borrowing-policy summary for Phase A:
- borrow Linux capability/fixup/MSI semantics as donor knowledge,
- reimplement them as typed Rust helpers in `redox-driver-sys` / `pcid`,
- prefer data-driven quirks over daemon-local special cases,
- and do not import Linux generic IRQ-core ownership into Red Bear.
Current implementation progress remains true but is intentionally summarized only:
- shared PCI capability parsing and interrupt-support summarization are already present in
`redox-driver-sys`,
- and the remaining rollout/convergence work now belongs to the canonical IRQ plan rather than this
borrowing-policy document.
### Phase B — ACPI / suspend / IOMMU
**Primary targets**
- `recipes/core/base/source/drivers/acpid/src/acpi.rs`
- `recipes/core/base/source/drivers/acpid/src/sleep.rs` (new)
- `local/recipes/system/iommu/source/src/main.rs`
- shared future IVRS/DMAR helper modules in `redox-driver-sys`
**Implement**
- Red Bear-native sleep coordinator
- `_PTS` / `_WAK` / wake-source handling helpers
- IVRS/DMAR parsers and table builders
- move long-term DMAR runtime ownership into `iommu`
**Acceptance**
- `_S5` preserved
- explicit sleep phase machine exists
- IOMMU ownership clarified and moved out of `acpid`
**Current implementation progress (2026-04-18)**
- `acpid` now has an explicit `SleepTarget` / `SleepPhase` model in userspace, naming `S1`, `S3`,
`S4`, and `S5` as Red Bear sleep targets.
- The real shutdown path now routes through that target model, while non-`S5` targets are
recognized but still remain groundwork-only rather than implemented suspend/resume support.
- Unit coverage exists for sleep-target parsing, AML sleep-object naming, and the current
Red Bear-native rule that only `S5` is treated as an implemented soft-off path today.
- This is still groundwork only: there is no claim of full suspend/resume or sleep eventing yet,
and Linux suspend sequencing remains reference material rather than imported structure.
- The `iommu` daemon now also detects the presence of a kernel ACPI `DMAR` table and reports that
Intel VT-d runtime ownership should converge there instead of remaining conceptually attached to
the old transitional `acpid` DMAR code, but that ownership is not yet cleanly closed in the
current tree.
### Phase C — PS/2 / USB / storage
**Primary targets**
- `recipes/core/base/source/drivers/input/ps2d/src/{controller,state}.rs`
- `recipes/core/base/source/drivers/usb/xhcid/src/xhci/*`
- `recipes/core/base/source/drivers/storage/usbscsid/src/*`
**Implement**
- PS/2 reset/resume hardening
- xHCI quirk and interface-selection corrections
- bounded storage heuristics from Linux SCSI logic
**Acceptance**
- PS/2 proof remains green
- xHCI and USB maturity proofs remain green
- no Linux USB/input-core structure imported
**Current implementation progress (2026-04-18)**
- `xhcid` now tracks active alternate settings per interface and resolves endpoint descriptors using
that active-alternate map instead of flattening all interface descriptors in a configuration.
- Direct unit coverage exists for default-alternate endpoint selection and alternate-setting-aware
endpoint remapping, closing the most explicit in-tree USB interface-selection TODO without
importing Linux USB-core structure.
- `xhcid` now also preserves previously selected alternates on the same configuration and applies a
requested interface/alternate override before endpoint planning, so alternate-setting
reconfiguration no longer silently falls back to all-zero defaults.
- `xhcid` endpoint-direction lookup now also follows the active interface/alternate selection state
instead of reading from the first configuration/interface pair unconditionally.
- `xhcid` driver spawning now also follows the selected configuration and active alternate map
instead of hardcoding the first configuration and ignoring non-zero alternates.
- `xhcid` now also has a preserve-and-grow event-ring path in the IRQ reactor, so `EventRingFull`
recovery no longer drops unread event TRBs while resizing the primary event ring.
- `usbhubd` and `xhcid` now propagate USB 2 hub TT Think Time from the parent hub descriptor into
the xHCI Slot Context TT information bits using a bounded Linux-compatible encoding path.
- `xhcid` endpoint-context calculations are now protocol-speed-aware for SuperSpeedPlus, so
interval and ESIT-payload selection distinguish SSP paths from generic SuperSpeed using the
resolved port protocol speed rather than only endpoint companion presence.
- `usbscsid` now has a bounded native `SYNCHRONIZE CACHE(10/16)` heuristic gated by the existing
`needs_sync_cache` storage quirk, directly reflecting the planned Linux `sd.c` donor usage without
importing Linux SCSI midlayer structure.
- `ps2d` now performs an explicit controller-output flush during probe and at the key controller
reinitialization boundaries in `Ps2::init()`, matching the Linux `i8042_flush()` discipline in a
bounded Red Bear-native way without importing Linux input-core structure.
### Phase D — Wi-Fi and GPU/DRM
**Primary targets**
- `local/recipes/system/redbear-wifictl/source/*`
- `local/recipes/system/redbear-netctl/source/*`
- `local/recipes/gpu/redox-drm/source/*`
**Implement**
- only reusable queue/DMA/IRQ helper extraction from bounded Wi-Fi donor transport
- only orchestration / phase sequencing / quirk policy extraction for DRM
**Acceptance**
- control plane remains native
- DRM display-vs-render boundary remains explicit
- no claim of full AMDGPU rewrite or Linux wireless-architecture import
**Current implementation progress (2026-04-18)**
- `redbear-wifictl` transport probing now uses the shared `redox-driver-sys` PCI parser and the
shared quirk-aware interrupt-support summary instead of relying only on local raw-config logic.
- This is a bounded helper extraction only: the native Wi-Fi control plane remains authoritative,
and there is still no import of Linux wireless subsystem structure.
- `redox-drm` now turns shared hotplug and vblank events into a queued scheme-visible
`EVENT_READ` surface for `card0`, with hotplug also reaching the matching connector handle.
That makes shared DRM event delivery observable without conflating it with render-fence
semantics.
## 4. Subsystem-specific code guidelines
### ACPI / suspend
- Use Linux power docs/source for sequencing and debugging principles only.
- Do not port Linux PM callback ownership.
- Keep ACPI policy in `acpid` and session-facing signaling in `redbear-sessiond`.
### PCI / IRQ
- Reimplement Linux capability/fixup logic as typed Rust helpers.
- Prefer data-driven quirks over daemon-local special cases.
### PS/2
- Treat current `serio` + `ps2d` as correct baseline.
- Only import missing deltas from Linux `i8042.c`.
### IOMMU
- Reimplement parsing/table logic in Rust.
- Keep runtime MMIO ownership in userspace `iommu`.
### USB
- Borrow Linux quirks and sequencing; keep controller ownership in Rust daemons.
- Do not recreate Linux USB driver registration models.
### Wi-Fi
- Keep Linux 80211 docs as reference-only behavior material.
- Keep `cfg80211` / `mac80211` / NAPI architecture out of Red Bear.
### GPU / DRM
- Use Linux DRM docs and donor code to inform orchestration and boundary discipline.
- Do not treat imported AMDGPU code as a roadmap for wholesale Rust replacement.
## 5. Validation and evidence rules
Every Linux-derived rewrite should clear these gates in order:
1. **Donor identified** — exact Linux source/doc named
2. **Rust landing point identified** — exact crate/module/file named
3. **Boundary stated** — rewrite target vs reference-only
4. **Build-valid** — compiles cleanly
5. **Runtime-valid** — bounded proof exists
6. **Hardware-valid** — only once target hardware evidence exists
Do not collapse those categories. Build success is not runtime proof, and runtime proof is not hardware support.
## 6. Final policy summary
The correct Red Bear approach is:
- borrow Linux **knowledge**, **algorithms**, **parsers**, **quirk semantics**, and **phase sequencing**
- rewrite those into **Rust helpers** and **Red Bear-native state machines**
- keep the **kernel minimal**
- keep **runtime/controller policy in userspace daemons**
- keep **`linux-kpi` bounded to GPU/Wi‑Fi donor islands only**
- avoid importing Linux subsystem ownership models into Red Bear OS
local/docs/QT6-PORT-STATUS.md
-451
View File
@@ -1,451 +0,0 @@
# Qt6 Port — Red Bear OS
**Last updated:** 2026-04-18
**Qt version:** 6.11.0
**Target:** x86_64-unknown-redox (cross-compiled from Linux x86_64 host)
> **Phase numbering note:** The phases below (Phase 1–6) are this document's internal Qt porting
> phases, not the canonical desktop plan phases. For the project-wide desktop execution plan
> (Phase 1: Runtime Substrate → Phase 5: Hardware GPU), see
> `local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v3.0).
**Qt Phase 1 status:** ✅ COMPLETE — Qt6 core stack + OpenGL/EGL + D-Bus + Wayland
**Qt Phase 2 status:** ✅ COMPLETE — All 32 KF6 frameworks built
**Qt Phase 3 status:** 🔄 IN PROGRESS — KWin + KDE Plasma build
> **Execution note (2026-04-17):** The repo now has a large Redox-desktop-relevant Qt 6.11 subset
> cook-verified across Waves 1–2, but this is not yet the same claim as full Redox-applicable Qt
> 6.11 coverage. Additional graphics / input / desktop-adjacent modules remain to be ported.
## Current Status Summary
| Component | Status | Details |
|-----------|--------|---------|
| **qtbase** | ✅ | 13 libs incl. OpenGL, EGL, DBus, WaylandClient |
| **qtdeclarative** | ✅ | 11 libs, QML JIT disabled |
| **qtsvg** | ✅ | 2 libs |
| **qtwayland** | ◐ Partial | Wayland client path verified; compositor slice still intentionally reduced in recipe |
| **qtimageformats** | ✅ | Real recipe + cook verified |
| **qt5compat** | ✅ | Real recipe + cook verified |
| **qttools** | ◐ Partial | Redox-scoped tooling slice cook verified; designer/assistant/qdoc/qtattributionsscanner intentionally omitted |
| **qttranslations** | ✅ | Translation catalogs cook verified |
| **qtshadertools** | ✅ | Real recipe + cook verified |
| **qtscxml** | ✅ | Real recipe + cook verified |
| **qtserialport** | ✅ | Real recipe + cook verified; unsupported modem-control ioctls mapped to runtime UnsupportedOperationError on Redox |
| **qtwebchannel** | ✅ | Real recipe + cook verified |
| **qtcharts** | ✅ | Real recipe + cook verified |
| **qtquicktimeline** | ✅ | Real recipe + cook verified after Qt Quick substrate export fixes |
| **Mesa EGL+GBM** | ✅ | libEGL, libgbm, libGLESv2, swrast DRI |
| **libdrm** | ✅ | libdrm + libdrm_amdgpu |
| **libinput** | ✅ | 1.30.2 with comprehensive redox.patch |
| **D-Bus** | ✅ | 1.16.2, libdbus-1.so |
| **KF6 Frameworks** | ✅ 32/32 | All frameworks built |
| **KWin** | 🔄 | Reduced recipe path now uses real `libxcvt`, `libepoxy`, `lcms2`, and honest `libudev.so` / `libdisplay-info.so` provider linkage; guest-side Qt plugin loading is fixed, but broader KWin runtime/session stability is still incomplete |
| **Hardware acceleration** | ❌ | PRIME/DMA-BUF scheme ioctls implemented; blocked on GPU command submission (CS ioctl) |
---
## Wave 1 — Redox-applicable Qt 6.11 module expansion
The first post-core Qt 6.11 coverage wave is now real-cook verified:
| Module | Status | Verification |
|--------|--------|--------------|
| `qtimageformats` | ✅ | `CI=1 ./target/release/repo cook qtimageformats` |
| `qt5compat` | ✅ | `CI=1 ./target/release/repo cook qt5compat` |
| `qttools` | ✅ | `CI=1 ./target/release/repo cook qttools` |
| `qttranslations` | ✅ | `CI=1 ./target/release/repo cook qttranslations` |
| `qtshadertools` | ✅ | `CI=1 ./target/release/repo cook qtshadertools` |
This means the repo now has real Qt 6.11 recipes for the first high-yield Redox-applicable
expansion set, all verified by actual `repo cook` runs.
## Wave 2 — Qt Quick / integration expansion
The second Redox-applicable Qt 6.11 wave is now also real-cook verified:
| Module | Status | Verification |
|--------|--------|--------------|
| `qtscxml` | ✅ | `CI=1 ./target/release/repo cook qtscxml` |
| `qtserialport` | ✅ | `CI=1 ./target/release/repo cook qtserialport` |
| `qtwebchannel` | ✅ | `CI=1 ./target/release/repo cook qtwebchannel` |
| `qtcharts` | ✅ | `CI=1 ./target/release/repo cook qtcharts` |
| `qtquicktimeline` | ✅ | `CI=1 ./target/release/repo cook qtquicktimeline` |
Wave 2 also required a real repair of the Qt Quick substrate rather than recipe-only leaf work:
- `qtbase` host build now uses a clean separate host build dir with `build/qt-host-build` as the install prefix.
- `qtshadertools` now installs a real host `qsb` and `Qt6ShaderToolsTools` package into that prefix.
- `qtdeclarative` now exports usable `Qt6Quick` / `Qt6Qml` CMake metadata to downstream Redox sysroots.
## Scope Definition
**Phase 1 scope**: qtbase, qtdeclarative, qtsvg — the foundational Qt6 stack.
Qt6 consists of many modules — each is a separate source package. Phase 2 (qtwayland + KF6 Tier 1)
follows in the next step.
**User-agreed scope constraints:**
- OpenGL: now enabled (GLES 2.0 software path via Mesa/LLVMpipe); hardware acceleration still future work
- Still disabled features: process testlib, sql, printsupport remain out of scope for current iteration
- Iterative approach: enable modules incrementally, re-enable disabled features later
## Build Status
### qtbase — Enabled Modules (7 libraries built)
| Module | Library | Size | Description |
|--------|---------|------|-------------|
| QtCore | libQt6Core.so.6.11.0 | 13 MB | Core non-GUI: event loop, IO, threads, plugins |
| QtConcurrent | libQt6Concurrent.so.6.11.0 | 26 KB | High-level multi-threading without locks |
| QtXml | libQt6Xml.so.6.11.0 | 212 KB | XML stream reader/writer (SAX/DOM) |
| QtGui | libQt6Gui.so.6.11.0 | 12 MB | GUI infra: images, painting, text, input, windowing |
| QtWidgets | libQt6Widgets.so.6.11.0 | 9.4 MB | Widget toolkit: buttons, layouts, dialogs |
| QtWaylandClient | libQt6WaylandClient.so.6.11.0 | — | Wayland client integration |
| QtWlShellIntegration | libQt6WlShellIntegration.so.6.11.0 | — | Wayland Shell integration |
### qtbase — Plugins (12 plugin libraries)
| Plugin | File | Type |
|--------|------|------|
| redox | libqredox.so | QPA platform |
| offscreen | libqoffscreen.so | QPA platform |
| minimal | libqminimal.so | QPA platform |
| wayland-bsoft-integration | libqwayland-bsoft-integration.so | Wayland integration |
| gif | libqgif.so | Image format |
| ico | libqico.so | Image format |
| jpeg | libqjpeg.so | Image format |
| png | libqpng.so | Image format |
| svg | libqsvg.so | Image format |
| iconengines | libqsvgicon.so | Icon engine |
| text | libqtext.so | Text platform |
| xkb | libqxkb.so | XKB support |
### qtdeclarative — Built Successfully (build 15)
| Library | Description |
|---------|-------------|
| libQt6Qml.so.6.11.0 | QML core |
| libQt6QmlModels.so.6.11.0 | Models (ListModel, etc.) |
| libQt6Quick.so.6.11.0 | QtQuick UI framework |
| libQt6QmlCore.so.6.11.0 | QML internals |
| libQt6QmlCompiler.so.6.11.0 | QML JIT compiler |
| libQt6QmlWorkerScript.so.6.11.0 | Worker script runtime |
| libQt6QmlMeta.so.6.11.0 | QML meta-object |
| libQt6QmlXmlListModel.so.6.11.0 | XML ListModel |
| libQt6LabsFolderListModel.so.6.11.0 | Folder list model |
| libQt6LabsQmlModels.so.6.11.0 | Lab models |
| libQt6LabsSettings.so.6.11.0 | Settings |
| libQt6LabsSynchronizer.so.6.11.0 | Synchronizer |
Plus: QML debug plugins, QtQuick/QML modules staged.
**Note**: QML JIT (`QT_FEATURE_qml_jit`) does not compile for Redox — disabled.
### qtsvg — Built Successfully
| Component | File |
|-----------|------|
| libQt6Svg.so.6.11.0 | SVG rendering |
| libQt6SvgWidgets.so.6.11.0 | SVG widget integration |
| qsvg icon engine | libqsvgicon.so |
| qsvg image format | libqsvg.so |
### Disabled Modules — Full Blocker Analysis
| Module | Status | Blocker | Re-enable Path |
|--------|--------|---------|----------------|
| QtNetwork | ✅ Re-enabled (2026-04-29) | DNS resolver hardened: use-after-free fix, FD leak fix, transaction ID validation, RCODE/TC handling | Recipe updated: `-DFEATURE_network=ON`, network subdirectory restored |
| QtSql | ❌ Disabled | User-agreed scope exclusion | Add sqlite/odbc recipe → enable QtSql |
| QtPrintSupport | ❌ Disabled | User-agreed scope exclusion, no printing subsystem on Redox | Port cups/filters → enable QtPrintSupport |
> **Previously disabled, now enabled:** QtOpenGL (✅ Phase 4b), QtOpenGLWidgets (✅ Phase 4b), and
> QtDBus (✅ Phase 2a) were disabled in earlier builds but have since been enabled and built
> successfully. See Phase 4b and Phase 2a sections below for details.
### Disabled Features — Full Blocker Analysis
| Feature | CMake Flag | Status | Notes |
|---------|-----------|--------|-------|
| XCB/Xlib | `-DFEATURE_xcb=OFF -DFEATURE_xlib=OFF` | ❌ Disabled | Not applicable — Redox uses Wayland |
| Vulkan | `-DFEATURE_vulkan=OFF` | ❌ Disabled | No Vulkan runtime on Redox |
| OpenSSL | `-DFEATURE_openssl=OFF` | ❌ Disabled | OpenSSL3 port in WIP but not validated |
| qmake | `-DFEATURE_qmake=OFF` | ❌ Disabled | Build tool, not needed with CMake |
| SQL | `-DFEATURE_sql=OFF` | ❌ Disabled | User-agreed scope exclusion |
| Print Support | `-DFEATURE_printsupport=OFF` | ❌ Disabled | User-agreed scope exclusion |
| QML JIT | `-DFEATURE_qml_jit=OFF` | ❌ Disabled | Does not compile for Redox |
> **Previously disabled, now enabled:** OpenGL (`-DFEATURE_opengl=ON`), EGL (`-DFEATURE_egl=ON`),
> and D-Bus (`-DFEATURE_dbus=ON`) were disabled in earlier builds but have since been enabled and
> built successfully. Process, shared memory, and system semaphore were also enabled after relibc
> improvements. See respective Phase sections for details.
---
## New Discoveries (Builds 8–17)
| # | Discovery | Fix |
|---|-----------|-----|
| 8 | qtwaylandscanner is a host tool, needs `FEATURE_qtwaylandscanner=ON` in both host and target builds | Enable feature in both cmake configs |
| 9 | wayland-scanner must be host binary — use `-DWaylandScanner_EXECUTABLE=/usr/bin/wayland-scanner` | Pass explicit path to host wayland-scanner |
| 10 | OpenGL guards needed in Wayland code (`#if QT_CONFIG(opengl)`) | Add guard in qtbase patch |
| 11 | `cmake --install` produces relocatable cmake files — replaced manual cmake copy | Use cmake install instead of manual sed |
| 12 | `QT_MKSPECS_DIR` must point to staged mkspecs — conditional in toolchain file | Add conditional logic in redox-toolchain.cmake |
| 13 | QtNetwork features leak into downstream — pass `QT_FEATURE_ssl=OFF` etc. | Explicitly disable in downstream cmake |
| 14 | SBOM generation fails — use `-DQT_GENERATE_SBOM=OFF` | Disable SBOM generation |
| 15 | Sysroot path mismatch — cookbook only symlinks bin/include/lib/share, need manual symlinks for plugins/mkspecs/metatypes/modules | Add manual symlinks in recipe |
| 16 | masm `CheckedArithmetic.h` missing `ArithmeticOperations<unsigned,long>` for LP64 | Add missing arithmetic operation to masm |
| 17 | QML JIT (`QT_FEATURE_qml_jit`) doesn't compile for Redox — disabled | Disable feature, works without JIT |
| 56 | **plasma-wayland-protocols** is a required separate package — kf6-kwayland needs PLASMA_WAYLAND_PROTOCOLS_DIR pointing to protocol XMLs | Created recipe that installs XML files + symlink for naming mismatch (org-kde-plasma-virtual-desktop.xml → plasma-virtual-desktop.xml) |
| 57 | **kf6-kcmutils** requires Qt6Quick unconditionally upstream | Strip Quick/QML/kcmshell from CMakeLists via Python-based source patching — produces libKF6KCMUtils.so + libKF6KCMUtilsCore.so (widget-only build) |
| 58 | **kf6-kwayland** fails with `get_filename_component called with incorrect number of arguments` when PLASMA_WAYLAND_PROTOCOLS_DIR is unset | Fix: create plasma-wayland-protocols package + point the cmake variable to the installed XMLs |
| 59 | **seatd** now builds as a standalone runtime package for Redox and is wired into the KDE runtime config; keep it out of KWin compile deps until DRM-lease/runtime validation exists | Runtime dependency only |
---
## Build Iteration History
| # | Issue | Fix |
|---|-------|-----|
| 1-7 | Patch format, byteswap.h, forwarding headers | Patch structure |
| 8 | qtwaylandscanner is host tool | `FEATURE_qtwaylandscanner=ON` in host+target |
| 9 | wayland-scanner must be host binary | `-DWaylandScanner_EXECUTABLE=/usr/bin/wayland-scanner` |
| 10 | OpenGL guards in Wayland code | `#if QT_CONFIG(opengl)` guard |
| 11 | cmake --install relocatable | Use cmake install over manual copy |
| 12 | QT_MKSPECS_DIR mismatch | Conditional in toolchain file |
| 13 | QtNetwork feature leak | Pass explicit QT_FEATURE_* flags |
| 14 | SBOM generation fails | `-DQT_GENERATE_SBOM=OFF` |
| 15 | Sysroot path mismatch (plugins/mkspecs/metatypes/modules) | Manual symlinks |
| 16 | masm CheckedArithmetic.h missing LP64 operation | Add ArithmeticOperations |
| 17 | QML JIT doesn't compile for Redox | Disable `QT_FEATURE_qml_jit` |
| **Phase 1** | **qtbase + qtdeclarative + qtsvg complete** | **✅ Core stack built** |
---
## relibc Status — Qt-facing Summary
The canonical relibc assessment now lives in:
- `local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md`
- `local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md`
This Qt status document should use those files as the source of truth instead of carrying a second,
more optimistic relibc inventory.
### Current Qt-facing relibc position
| Area | Current state for Qt/KDE work |
|-----|-------------------------------|
| fd-event APIs | The active relibc recipe patch chain provides bounded `eventfd`, `signalfd`, `timerfd`, and `waitid()` support. These should be treated as recipe-applied compatibility, not plain-source upstream convergence. |
| shared memory and semaphores | The active build now includes a bounded named-semaphore path through the relibc recipe surface. Broader SysV shm/sem work remains deferred outside the current concrete wave, and runtime trust for real Qt/KDE consumer paths is still the key remaining question. |
| interface discovery | `ifaddrs` / `net_if` support currently comes from a bounded Red Bear patch layer with a synthetic `loopback` + `eth0` model, not full live interface enumeration. |
| still-missing surfaces | Message queues remain absent, and broader relibc completeness work is still open in the live source tree. |
### Qt/KDE-facing relibc gaps that still matter
| Gap | Impact | Module blocked or pressured |
|-----|--------|----------------------------|
| broader networking runtime validation | QtNetwork end-to-end behavior | QtNetwork |
| broader shared-memory validation beyond the existing `shm_open()` path | shared memory confidence | QSharedMemory |
| broader semaphore and SysV-IPC runtime validation | semaphore and IPC confidence | QSystemSemaphore and direct KDE consumers |
| process/runtime validation beyond the bounded `waitid()` path | process-control confidence | QProcess |
| GPU hardware display validation | hardware-accelerated rendering | QtOpenGL hardware path |
The practical takeaway is that relibc is no longer blocked on raw fd-event API absence, but Qt/KDE
still depends on more proof and more semantic hardening than the current patch-applied surface alone
provides.
In the current pass, the active bounded relibc wave was also revalidated through focused relibc
tests for `eventfd`, `signalfd`, `timerfd`, `waitid`, named and unnamed semaphores,
`open_memstream`, and the bounded `ifaddrs` surface.
---
## Next Steps
### Phase 2a — qtbase D-Bus Enablement (✅ COMPLETE)
- qtbase target build: `-DFEATURE_dbus=ON` (Qt6DBus module built and staged)
- qtbase host build: `-DFEATURE_dbus=OFF` (qdbus tools provisioned via /usr/bin symlinks)
- libQt6DBus.so + Qt6DBusConfig.cmake + Qt6DBus.pc staged to sysroot
- D-Bus 1.16.2 already built (24-line redox.patch for epoll + socketpair)
- Unblocks: kf6-kdbusaddons, kf6-kservice, kf6-kpackage, kf6-kglobalaccel
- D-Bus plan: `local/docs/DBUS-INTEGRATION-PLAN.md` — redbear-sessiond login1 broker + D-Bus service infrastructure for KDE Plasma
**redbear-sessiond:** Implemented. Rust daemon at `local/recipes/system/redbear-sessiond/` using zbus 5, serving `org.freedesktop.login1` Manager/Session/Seat interfaces on the system bus. Maps `TakeDevice(major, minor)` to Redox scheme paths (`/scheme/drm/card0`, `/dev/input/eventN`). Config wired in `config/redbear-full.toml` with init service at slot 13.
**qdbuscpp2xml/qdbusxml2cpp provisioning:** Qt host build has `FEATURE_dbus=OFF` with these tools disabled. KDE recipes provision them via symlinks: kf6-kdbusaddons falls back to `/usr/bin/qdbuscpp2xml` and `/usr/bin/qdbusxml2cpp` from the host system. This works for cross-compilation but is not a long-term solution. Future improvement: enable FEATURE_dbus=ON in host build once D-Bus session bus validation passes.
**KF6 D-Bus re-enablement roadmap:** 15 KF6 components currently build with `-DUSE_DBUS=OFF`. Re-enablement is gated on D-Bus service availability: kf6-knotifications needs `org.freedesktop.Notifications` (DB-2, now enabled against a stub notification daemon), while kf6-solid needs `org.freedesktop.UPower` + `org.freedesktop.UDisks2` only after those services are consumer-trustworthy. The current UDisks2 path is much closer to that bar than UPower; the ACPI-backed UPower surface remains provisional until Wave 3 in `local/docs/ACPI-IMPROVEMENT-PLAN.md` closes. The runtime proof harness is now in place, but `kf6-solid` still keeps `-DUSE_DBUS=OFF`, `-DBUILD_DEVICE_BACKEND_upower=OFF`, and `-DBUILD_DEVICE_BACKEND_udisks2=OFF` until `solid-hardware6`/Phase 6 validation can confirm the consumer path. kf6-kio and 10 others need full desktop services (DB-5). See `local/docs/DBUS-INTEGRATION-PLAN.md` Section 14 for the complete matrix.
**Key insight:** QtDBus is NOT the gap — Qt6DBus builds and kf6-kdbusaddons provides the KDE convenience layer. The gap is the freedesktop service contracts (login1, Notifications, UPower, UDisks2, PolicyKit) that need Redox-native implementations. NetworkManager is deferred; Red Bear OS uses `redbear-netctl` for now.
### Phase 2b — qtwayland Module (◐ Client path complete, compositor slice intentionally reduced)
- Recipe at `recipes/wip/qt/qtwayland/recipe.toml`
- Uses redox-toolchain.cmake + host Qt build pattern
- Wayland client path is built and staged; compositor-side coverage remains intentionally reduced in the recipe
- OpenGL guards applied for software rendering
### Phase 2c — Input Stack (✅ COMPLETE)
- linux-input-headers: ✅ Built — provides linux/input.h + linux/types.h + _CNT macros
- libevdev 1.13.2: ✅ Built — uinput stubs + input.h __redox__ guard
- libinput 1.30.2: ✅ Built — comprehensive redox.patch:
- SYS_pidfd_open meson guard (cc.has_header check)
- Non-udev shim (libudev stub for HAVE_UDEV=0)
- Vendored Linux input.h selection for __redox__
- strtod_l() fallback
- timerfd path still warrants broader consumer-confidence review, but relibc now has strict Redox-target runtime proof for the bounded timerfd harness
- Linux-only tool binaries skipped on Redox
### Phase 3 — KF6 Frameworks (✅ ALL 32 BUILT)
All KF6 frameworks built and staged:
ecm, kcoreaddons, kwidgetsaddons, kconfig, ki18n, kcodecs, kguiaddons, kcolorscheme,
kauth, kwindowsystem, knotifications, kjobwidgets, kconfigwidgets, karchive, sonnet,
kcompletion, kitemviews, kitemmodels, solid, kdbusaddons, kservice, kpackage,
kcrash, ktextwidgets, kiconthemes, kglobalaccel, kdeclarative, kxmlgui, kbookmarks,
kidletime, kio, kcmutils
Additional KDE packages:
- kdecoration ✅ BUILT (KDecoration3 window decoration library)
- kirigami ✅ STUB ONLY (dependency-resolution package, not a real runtime-ready Kirigami build)
- kf6-kwayland ✅ BUILT
- kf6-kcmutils ✅ BUILT (widget-only, Quick/QML/kcmshell stripped)
- plasma-wayland-protocols ✅ BUILT (protocol XMLs for kf6-kwayland)
Graphics stack (PRIMARY DELIVERABLE):
- Mesa EGL+GBM ✅ BUILT (libEGL.so, libgbm.so, libGLESv2.so, swrast_dri.so)
- libdrm amdgpu ✅ BUILT (libdrm_amdgpu.so, /scheme/drm/ paths)
- Qt6 OpenGL ✅ BUILT (libQt6OpenGL.so, libQt6EglFSDeviceIntegration.so, GLES 2.0)
- D-Bus ✅ BUILT (libdbus-1.so.3.38.3, dbus-daemon)
- libinput ✅ BUILT (libinput.so.10.13.0, comprehensive redox.patch)
- libevdev ✅ BUILT (libevdev.so.2.3.0, uinput stubs)
KWin recipe updated with 40 dependencies (all KF6 + Mesa + libdrm + libinput + qtwayland).
plasma-workspace, plasma-desktop recipes created.
### Phase 4 — Graphics Stack (✅ build-side complete, 🚧 runtime incomplete)
Mesa EGL+GBM+GLES2 built:
- libEGL.so (225KB) — platforms: redox, surfaceless, drm
- libgbm.so (68KB) — Generic Buffer Manager for compositor buffer allocation
- libGLESv2.so — OpenGL ES 2.0 (software via LLVMpipe)
- libGLESv1_CM.so — OpenGL ES 1.1
- swrast_dri.so + kms_swrast_dri.so — LLVMpipe software DRI drivers
- pkgconfig: egl.pc, gbm.pc, osmesa.pc, glesv2.pc, dri.pc
libdrm amdgpu enabled:
- libdrm_amdgpu.so (48KB) — AMD GPU DRM API
- Device paths: /scheme/drm/cardN, /scheme/drm/renderD
Qt6 OpenGL enabled:
- libQt6OpenGL.so (716KB) — Qt OpenGL module (GLES 2.0 path)
- libQt6OpenGLWidgets.so — Qt OpenGL widgets
- libQt6EglFSDeviceIntegration.so — EGLFS platform integration
- EGLFS KMS plugin for direct DRM/KMS rendering
Current truth for Phase 4:
- the graphics stack now builds end to end: Mesa EGL+GBM+GLES2, libdrm amdgpu, Qt6 OpenGL/EGL,
and qtwayland all stage successfully
- the historical `redbear-wayland` validation profile and the current bounded `redbear-full` QEMU validation surface are still runtime-validation paths,
not proof of a hardware-accelerated desktop session
- the current QEMU validation harness is still software-rendered (`llvmpipe`) and should be treated
as a bounded regression/test path, not as the final acceleration proof target
- the earlier guest-side Qt bootstrap/plugin blocker is now fixed: bounded guest checks load both
`libqminimal.so` and KWin's `qwayland-org.kde.kwin.qpa.so`, but compositor-backed runtime proof
is still incomplete because KWin/session stability remains open
- true hardware-accelerated desktop readiness still requires GPU command submission (CS ioctl) plus real
AMD/Intel hardware validation through the DRM → GBM/EGL → compositor → Qt client path
(PRIME/DMA-BUF cross-process buffer sharing is implemented at scheme level)
### Phase 4b — Qt6 OpenGL Enablement (✅ build-side complete, 🚧 runtime incomplete)
qtbase rebuilt with `-DFEATURE_opengl=ON -DINPUT_opengl=es2 -DFEATURE_egl=ON`
Qt cmake summary: EGL=yes, OpenGL=yes, "OpenGL ES 2.0=yes, EGLFS GBM=yes"
### Phase 5 — KDE Plasma / desktop-session layer (🔄 IN PROGRESS)
KDE Plasma packages built:
- kf6-kwayland ✅ BUILT
- kf6-kcmutils ✅ BUILT (widget-only, Quick/QML/kcmshell stripped)
- kirigami ✅ STUB ONLY (dependency-resolution package, not a real runtime-ready Kirigami build)
- plasma-wayland-protocols ✅ BUILT (protocol XMLs for kf6-kwayland)
- kdecoration ✅ BUILT (KDecoration3 window decoration library)
plasma-workspace stub dependencies partially resolved:
- kf6-knewstuff ✅ STUB ONLY (KF6NewStuff cmake INTERFACE IMPORTED targets for plasma-workspace dep resolution)
- kf6-kwallet ⚠️ EXISTS IN-TREE (real API-only cmake build; not in current redbear-full enabled subset)
- kf6-prison ✅ REAL RECIPE (real cmake build against libqrencode; dmtx/ZXing disabled; not yet compiled)
qt6-wayland-smoke improved to create a visible QWindow:
- Creates a 320x240 colored window (red background, "Red Bear OS - Qt6 Wayland Smoke Test" text)
- Uses QBackingStore for software rendering
- Runs for 3 seconds (previously 1 second, no window)
- This turns the smoke test from a bootstrap check into a real Wayland surface proof target
KWin recipe provides cmake config stubs and kwin_wayland_wrapper scripts that delegate to redbear-compositor (features re-enabled where deps are satisfied):
- KWIN_BUILD_DECORATIONS=ON (kdecoration builds ✅)
- KWIN_BUILD_RUNNERS=ON (kf6-kio builds ✅)
- USE_DBUS=ON (D-Bus 1.16.2 builds ✅)
- Still disabled (11): global shortcuts, notifications, KCMS, screen locking, tabbox,
effects, legacy windowing backend, QML, running-in-kde, signing docs, screenlocker
- Honest reduced-path providers now integrated into the current recipe: libepoxy, lcms2, libudev, libdisplay-info
- Remaining limitation in that dependency slice: `libudev` hotplug monitoring is bounded, and `libdisplay-info` is currently base-EDID only (CTA / DisplayID / HDR metadata still unsupported)
New dependency library:
- libqrencode 4.1.1 ✅ BUILT (QR code encoder, dependency of kf6-prison)
- kf6-kwayland ✅
- seatd builds separately (runtime dependency, not needed for compilation)
### Phase 6 — KWin (✅ stub recipe provides cmake configs + wrapper scripts; 🚧 real build needs Qt6Quick)
## Dependency Graph
```
Phase 1 ✅ (qtbase + qtdeclarative + qtsvg)
└── Phase 2a ✅ (D-Bus daemon + qtbase D-Bus enablement)
└── Phase 2b ✅ (qtwayland built)
└── Phase 2c ✅ (libevdev + libinput built)
└── Phase 3 ✅ (KF6 — ALL 32 frameworks built)
└── Phase 4 ✅ build-side / 🚧 runtime (Mesa EGL+GBM+GLES2, Qt6 OpenGL+EGL, libdrm amdgpu)
└── Phase 5 🔄 (kdecoration ✅, kf6-kwayland ✅, kirigami stub-only, KWin still blocked on shimmed/scaffolded deps)
```
---
## Known Issues
1. **QML JIT disabled** — `QT_FEATURE_qml_jit` does not compile for Redox. QML still works
via the interpreter path, just without JIT acceleration. Non-blocking for basic QML apps.
2. **QtNetwork disabled** — relibc now exposes bounded resolver compatibility (`resolv.h`,
`arpa/nameser.h`, `res_query`, `res_search`), but DNS/runtime semantics and IPv6 multicast
coverage are still incomplete. HTTP/WebSocket remain unavailable until relibc networking is
validated more broadly. QML network access is also affected.
3. **No GPU hardware acceleration** — Qt6 OpenGL/EGL and Mesa EGL+GBM now build, but they are still validated only on the software/LLVMpipe path.
True hardware acceleration (radeonsi or equivalent) still requires GPU command submission and real hardware validation.
PRIME/DMA-BUF cross-process buffer sharing is implemented at the scheme level.
4. **relibc / graphics surface still incomplete for runtime** — the build-side `open_memstream` and Wayland-facing header export path now work,
and DMA-BUF ioctls plus a bounded private CS surface now exist, but real sync objects/shared fence semantics and broader graphics runtime validation are still unavailable.
5. **KDE Plasma does NOT run end-to-end yet** — KWin, plasma-workspace, plasma-desktop recipes exist,
and KWin is a stub recipe (cmake configs + kwin_wayland_wrapper delegating to redbear-compositor) with honest `libudev.so` / `libdisplay-info.so` linkage and a successful current `kwin` cook, but runtime integration, compositor validation, and broader Plasma session proof are still missing.
## Honest Status Assessment
The Qt6/KF6 build stack is substantially further along than the earlier "~50%" estimate implied:
- Qt6, QtWayland, Mesa EGL+GBM, Qt6 OpenGL, libdrm amdgpu, and all 32 KF6 frameworks now build
- the remaining blockers are concentrated in KWin/Plasma runtime integration and in the still-shimmed or stub-only packages such as Kirigami, plus the bounded-not-full provider behavior of `libudev` and `libdisplay-info` in the current KWin stub path
- hardware acceleration still requires GPU command submission and real hardware validation (PRIME/DMA-BUF buffer sharing is implemented)
- a successful build stack is not yet the same thing as a working KDE Plasma session
For the canonical execution plan from this state to a working KDE Plasma desktop, see
`local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md` (v3.0). The Qt work described here maps to
pre-Phase work (builds complete) and Phase 3 (KWin desktop session) in the canonical plan.
(Updated 2026-04-29 — aligned with CONSOLE-TO-KDE-DESKTOP-PLAN.md v3.0)
local/docs/REDBEAR-INFO-RUNTIME-REPORT.md
-86
View File
@@ -1,86 +0,0 @@
# redbear-info Runtime Report
`redbear-info` is the canonical Red Bear OS runtime integration and debugging command.
## Purpose
The tool is intentionally passive. It reports what the running system can actually prove through
read-only runtime surfaces instead of flattening everything into a single “available” bit.
It is meant to answer:
- what Red Bear integrations are installed,
- what services or schemes are actually active,
- what integrations passed a safe read-only runtime probe,
- whether networking is configured, including IP, DNS, and default route,
- whether key hardware discovery surfaces (PCI, USB, DRM, RTL8125, VirtIO NICs) are visible.
## Output model
Each integration is reported with one of these layered states:
- `absent` — no artifact or runtime surface was observed
- `present` — an artifact or config exists, but there is no live runtime proof yet
- `active` — a live runtime surface exists, but the probe cannot honestly claim full working order
- `functional` — a safe read-only runtime probe succeeded
- `unobservable` — no honest runtime proof exists for a deeper claim
This distinction matters because some Red Bear integrations compile or package cleanly before they
are hardware-validated at runtime.
## Current sections
`redbear-info` reports:
- **Identity** — OS name, version, hostname
- **Networking** — stack state, connected flag, interface, MAC, IP/CIDR, DNS, default route,
active `netctl` profile, visible `network.*` schemes, Wi-Fi control/firmware/transport surfaces,
and bounded Bluetooth transport/control visibility
- **Hardware** — PCI device count, USB controller count, DRM card count, RTL8125 PCI visibility,
VirtIO NIC visibility for VM baselines
- **Hardware** — bounded PCI interrupt-support summary (`none`, `legacy`, `msi`, `msix`) derived
from the shared `redox-driver-sys` parser instead of a second local decoder
- **Integrations** — tools, daemons, and integration paths such as `lspci`, `lsusb`, `netctl`,
`pcid-spawner`, `smolnetd`, `firmware-loader`, `udev-shim`, `evdevd`, `redox-drm`,
`redbear-wifictl`, `redbear-btusb`, `redbear-btctl`, and the native RTL8125 and VirtIO
networking paths
For Phase 3 runtime validation, `udev-shim` is expected at `/usr/bin/udev-shim` and `evdevd` is
expected at both `/usr/bin/evdevd` and `/usr/lib/drivers/evdevd` so service execution and runtime
reporting use the same binary identity.
## Commands
- `redbear-info` — human-readable report
- `redbear-info --verbose` — includes evidence and claim limits
- `redbear-info --json` — structured machine-readable output
- `redbear-info --test` — suggested follow-up diagnostic commands
## Maintenance rule
Whenever Red Bear adds or materially changes an integration, update `redbear-info` in the same
change set.
That includes new:
- user-facing tools
- scheme daemons
- services
- hardware integration paths
- configuration layers that users rely on to debug a running image
Recent examples include the Wi-Fi control-plane surfaces and the bounded Bluetooth first-slice
surfaces, both of which extend the runtime report without over-claiming hardware validation.
Recent PCI/IRQ examples now also include:
- aggregate interrupt-support counts in the hardware section,
- bounded `redbear-upower` integration reporting tied to the live `/scheme/acpi/power` surface,
- the distinction between “PCI device visible” and “PCI interrupt mode/runtime proof is still a
bounded claim”,
- and normalized bounded proof outputs from the MSI-X and xHCI QEMU helpers (`IRQ_DRIVER`,
`IRQ_MODE`, `IRQ_REASON`, `IRQ_LOG`) so the current proof surface says which mode was actually
observed and why the driver believed it was using that path.
The goal is for `redbear-info` to remain the first command users run when they need to understand
the state of a Red Bear system.
local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md
-334
View File
@@ -1,334 +0,0 @@
# Red Bear OS relibc Assessment and Improvement Plan
## Purpose
This document is the canonical Red Bear assessment of relibc quality, completeness, and robustness.
It is intentionally stricter than older relibc notes. This pass is grounded in what is visible in:
- the upstream-owned working tree under `recipes/core/relibc/source/`,
- the active relibc recipe patch list in `recipes/core/relibc/recipe.toml`,
- the durable Red Bear patch carriers under `local/patches/relibc/`,
- and the tests added by the active patch chain.
It does **not** flatten those evidence types into one generic claim of "implemented".
## Evidence model
Use these labels consistently when describing relibc in this repository:
- **plain-source-visible**: present in the current upstream-owned `recipes/core/relibc/source/` tree without relying on recipe patch replay
- **recipe-applied**: added only when the active relibc recipe replays Red Bear patch carriers
- **test-present**: test coverage exists in the source tree or the active patch chain
- **documented downstream build evidence**: another in-repo document records downstream build success, but that success was not re-executed as part of this documentation pass
- **runtime-unrevalidated in this pass**: do not describe as runtime-trusted here unless this review actually reran it
This distinction matters because the largest relibc documentation problem in the repo was overclaiming
plain-source convergence when the active build still depends on a substantial recipe-applied patch
chain.
## Ownership boundary
- `recipes/core/relibc/source/` is an upstream-owned working tree and may be replaced on refresh.
- `recipes/core/relibc/recipe.toml` defines the currently active relibc build surface.
- `local/patches/relibc/` is the durable Red Bear compatibility carrier set.
- `local/docs/` is the durable explanation of what Red Bear currently depends on and why.
For relibc, the honest maintenance target is:
> fresh upstream relibc sources can be refetched, the active Red Bear relibc patch chain can be
> replayed, and the same intended build surface can be reconstructed.
## Current implementation assessment
### 1. Plain source and active build are materially different
The current upstream-owned header tree still contains clear incompleteness markers in
`recipes/core/relibc/source/src/header/mod.rs`, including:
- `iconv.h`
- `mqueue.h`
- `spawn.h`
- `sys/msg.h`
- `threads.h`
- `wordexp.h`
The live source tree also still shows relibc areas that are **not** yet plain-source-complete:
- `recipes/core/relibc/source/src/header/semaphore/mod.rs` still contains `todo!("named semaphores")`
- `recipes/core/relibc/source/src/header/ifaddrs/mod.rs` still returns `ENOSYS`
- `recipes/core/relibc/source/src/header/mod.rs` still keeps `sys/ipc.h`, `sys/sem.h`, and `sys/shm.h` behind TODO comments
That means older wording such as "now source-visible in the current tree" was too strong for much of
the current relibc surface.
### 2. The active relibc build relies on a broad patch chain
The active recipe in `recipes/core/relibc/recipe.toml` currently replays more than `redox.patch`.
The tracked patch list still includes, among others:
- `redox.patch`
- `P0-strtold-cpp-linkage-and-compat.patch`
- `P3-signalfd.patch`
- `P3-signalfd-header.patch`
- `P3-timerfd-relative.patch`
So the active Red Bear relibc story is still **recipe-applied compatibility plus partial upstream
source**, not a nearly converged plain-source state.
### 3. What the active patch chain actually provides
Observed directly from the current patch set:
- `P3-signalfd.patch`: adds `signalfd` / `signalfd4` support through `/scheme/event` plus signal-mask handling
- `P3-timerfd-relative.patch`: adds `sys/timerfd.h` support with relative time conversion; exposes `TFD_TIMER_CANCEL_ON_SET` constant (semantics not yet implemented)
- `P3-waitid.patch`: adds a bounded `waitid()` implementation plus a focused test
- `P3-semaphore-fixes.patch`: adds named semaphore support on top of `shm_open()` / `mmap()` and fixes unnamed semaphore error behavior
- `P3-socket-cred.patch`: adds `SO_PEERCRED` and `getpeereid`
- `P3-open-memstream.patch`: adds `open_memstream()` plus a focused stdio test
- `P3-ifaddrs-net_if.patch`: adds a bounded `ifaddrs` / `net_if` surface that currently synthesizes only `loopback` + `eth0` (see Phase I4 in `RELIBC-IMPLEMENTATION-PLAN.md` for the live-discovery upgrade path)
- `P3-fd-event-tests.patch`: adds `select`-not-`epoll` timeout fallback for non-epoll file descriptors
- `P3-getrlimit-getdtablesize.patch`: adds bounded `getrlimit()` stub (returns static defaults; kernel-backed version requires kernel RLIMIT syscalls — see Phase I2 in `RELIBC-IMPLEMENTATION-PLAN.md`)
- `P3-in6-pktinfo.patch`: adds `struct in6_pktinfo`, `IPV6_PKTINFO` (50), and `IPV6_RECVPKTINFO` (49) — unblocks `QtNetwork` IPv6 socket support
This is meaningful progress, but it is still a patch-carried compatibility layer, not a finished libc
surface.
### 4. Fresh bounded-wave verification in this pass
This documentation pass also executed a fresh bounded relibc verification cycle against the active
recipe surface:
- `./target/release/repo unfetch relibc`
- `./target/release/repo fetch relibc`
- `./target/release/repo cook relibc`
- targeted `relibc-tests-bins` executions for:
- `sys_eventfd/eventfd`
- `sys_signalfd/signalfd`
- `sys_timerfd/timerfd`
- `waitid`
- `semaphore/named`
- `semaphore/unnamed`
- `stdio/open_memstream`
- `ifaddrs/getifaddrs`
These are bounded relibc-target proofs, not broad desktop-session runtime proof. They do, however,
move the active concrete-wave surface from documented intent to directly revalidated recipe behavior.
## Quality assessment
### Strong points
1. **The patch carriers are explicit and reviewable.**
The relibc recipe points at named patch files instead of hiding Red Bear behavior in an
untracked working tree.
2. **Several high-value desktop-facing APIs exist in the active build.**
`eventfd`, `signalfd`, `timerfd`, `waitid`, and named semaphore support are all represented in the
active patch chain instead of remaining vague TODO items.
3. **Focused tests now exist for the active concrete-wave surface and were rerun in this pass.**
The current patch chain now covers `eventfd`, `signalfd`, `timerfd`, `waitid`, named and unnamed
semaphores, `open_memstream`, and the bounded `ifaddrs` view.
4. **The build integration point is simple and durable.**
The active surface is controlled centrally from `recipes/core/relibc/recipe.toml` and durable
carriers under `local/patches/relibc/`.
### Weak points
1. **The repo has drifted between plain-source truth and documentation truth.**
Several canonical docs previously described patch-carried functionality as if it already existed
in the plain upstream-owned source tree.
2. **The active API surface is broader than its semantic maturity.**
The patch chain exposes interfaces, but several of them are bounded compatibility layers rather
than broad Unix-complete implementations.
3. **Patch-chain size is still a maintainability risk.**
The active recipe still depends on a substantial set of P3 carriers. That is workable, but it is
not yet the convergence story older docs implied.
## Completeness assessment
### Plain-source-visible gaps
Still absent or TODO in the live source tree:
- `mqueue.h`
- `sys/msg.h`
- named semaphores in `semaphore.h`
- `ifaddrs` plain-source implementation
- plain-source `sys/ipc.h`, `sys/sem.h`, and `sys/shm.h`
### Recipe-applied but bounded surfaces
The active build surface includes several features that should be described as **bounded**, not
fully complete:
- `timerfd`: the patch exposes `TFD_TIMER_CANCEL_ON_SET`; relative timers are now converted to
absolute in userspace via `P3-timerfd-relative.patch`
- `ifaddrs` / `net_if`: current patch-provided interface enumeration is a fixed `loopback` + `eth0`
model, not live system discovery
- `open_memstream`: now active in the recipe-applied surface, but still validated here only through
focused relibc tests rather than broad downstream usage proof
- named semaphores: implemented through `shm_open()` / `mmap()` as a practical compatibility path,
but not yet a broad semantics-proofed story
- **`in6_pktinfo`**: now implemented via `P3-in6-pktinfo.patch` — adds `struct in6_pktinfo`,
`IPV6_PKTINFO` (50), and `IPV6_RECVPKTINFO` (49) — unblocks `QtNetwork` IPv6 socket support
### Still-missing areas
The clearest remaining gaps are still real gaps, not just "needs more runtime proof":
- POSIX message queues
- SysV message queues
- broader thread / spawn / iconv / wordexp completeness
The broader SysV shm/sem carriers still exist under `local/patches/relibc/`, but they are not part
of the active bounded concrete wave implemented in this pass.
## Robustness assessment
Robustness is the weakest part of the current relibc story.
The repo now has a meaningful active patch-applied compatibility surface, but several pieces are
still narrow enough that the safest language is:
- useful for bounded downstream compatibility,
- not yet broad semantics-proof,
- and not yet safely describable as a plain-source upstream relibc completion story.
Concretely:
- fd-event APIs depend on scheme paths such as `/scheme/event` and `/scheme/time`
- `ifaddrs` currently reports a synthetic interface view rather than live network state
- named semaphores remain a bounded shm-backed path rather than a broader semantics-proofed story
## Recommended support language
Use this language in project docs unless stronger evidence is gathered:
- **Good:** "The active relibc recipe patch chain provides bounded `eventfd` / `signalfd` /
`timerfd` compatibility for current Red Bear consumers."
- **Good:** "Named semaphores and `ifaddrs` currently exist through recipe-applied Red Bear
compatibility patches, not as plain-source upstream relibc convergence."
- **Avoid:** "These surfaces are now source-visible in the current relibc tree."
- **Avoid:** "relibc is complete for desktop consumers."
## Improvement plan
### Phase R0 — Keep the evidence model honest
Goals:
- keep plain-source, recipe-applied, and runtime-proof language distinct
- keep canonical relibc docs aligned with `recipes/core/relibc/recipe.toml`
- stop describing patch-carried functionality as already upstream-visible unless it really is
Exit criteria:
- relibc docs match the active recipe patch list
- repo-level summaries use bounded/evidence-qualified language
### Phase R1 — Make the active patch chain the explicit build contract
Goals:
- treat the current relibc recipe patch list as the build contract for Red Bear relibc behavior
- review that list regularly against upstream relibc changes
- retire carriers only when the recipe no longer needs them
Exit criteria:
- every relibc carrier still replayed by the recipe is documented as active
- every historical-but-not-active carrier is clearly marked historical
### Phase R2 — Strengthen proof for the patch-applied surface
Goals:
- keep focused tests for `waitid`, semaphores, and other patch-applied APIs
- expand consumer-facing checks for the APIs Red Bear actually depends on
- avoid treating build success alone as semantics proof
Exit criteria:
- each active compatibility surface names its current proof level and missing proof
### Phase R3 — Harden bounded compatibility layers
Highest-value targets:
- fd-event semantics that current desktop consumers rely on
- named semaphore behavior beyond the current narrow shm-backed path
- `ifaddrs` / `net_if` behavior beyond the synthetic `loopback` + `eth0` model
Exit criteria:
- docs no longer need to caveat these areas as merely synthetic or narrowly bounded unless that
boundedness is intentional and accepted
### Phase R4 — Decide the real SysV IPC contract
The current bounded SysV shm/sem layer is better than raw absence, but it is not a broad final
design.
Decision needed:
- either keep a clearly documented bounded compatibility contract,
- or implement a broader system-backed contract and test it accordingly.
Exit criteria:
- the repo stops implying broad SysV completeness where only a narrow compatibility slice exists
### Phase R5 — Triage the still-missing surfaces
Priority candidates:
- message queues,
- thread/spawn completeness,
- other TODO headers that block real consumers rather than theoretical completeness checklists.
Exit criteria:
- each remaining TODO surface is either implemented, explicitly deferred, or removed from misleading
summary language
### Phase R6 — Converge with upstream where possible
Goals:
- shrink the relibc patch chain whenever upstream absorbs equivalent behavior
- avoid carrying Red Bear-local relibc deltas longer than necessary
Exit criteria:
- the active recipe patch chain is smaller for evidence-based reasons, not for documentation optics
## Bottom line
relibc in the current Red Bear repo is neither a greenfield libc nor a nearly converged upstream
story.
It is a **partially upstream, materially patch-applied compatibility surface** that already covers
important desktop-facing APIs, but still has real completeness gaps, bounded semantics, and a larger
patch-chain dependency than older docs admitted.
## Implementation roadmap
For detailed engineering plans targeting specific gaps, see
`local/docs/RELIBC-IMPLEMENTATION-PLAN.md`. That document supersedes the R0–R6 phase structure
here for gap-specific work, while this document remains the canonical quality and evidence model
reference.
Current implementation priorities from `RELIBC-IMPLEMENTATION-PLAN.md`:
| Gap | Status | Phase |
|-----|--------|-------|
| `in6_pktinfo` + `IPV6_PKTINFO` | ✅ Implemented (`P3-in6-pktinfo.patch`) | I1 |
| `getrlimit`/`setrlimit` advisory impl | ✅ Implemented — `setrlimit` returns `Ok`, added `RLIMIT_NPROC`/`NICE`/`RTPRIO`/`MSGQUEUE` defaults (`P3-getrlimit-getdtablesize.patch`) | I2 |
| `timerfd` relative time | ✅ Implemented (`P3-timerfd-relative.patch`) -- `TFD_TIMER_CANCEL_ON_SET` still pending | I3 |
| `ifaddrs` live discovery | Improved synthetic: 3 entries (loopback, eth0, wlan0) via `P3-ifaddrs-net_if.patch`; scheme-based enumeration deferred | I4 |
| Plain-source TODO headers | Partially completed: `spawn.h` (posix_spawn via `P3-spawn.patch`), `threads.h` (C11 types via `P3-threads.patch`); `mqueue.h`, `iconv.h`, `wordexp.h` deferred | I5 |
local/docs/RELIBC-COMPREHENSIVE-ASSESSMENT.md
-344
View File
@@ -1,344 +0,0 @@
# Red Bear OS — relibc Comprehensive Assessment and Action Plan
**Generated**: 2026-04-29
**Scope**: End-to-end relibc readiness assessment for Red Bear OS
**Authority**: This document supersedes all previous relibc planning docs. It is the single source of truth.
---
## 1. Executive Summary
relibc is the Rust-based POSIX C library used by Red Bear OS. It sits between applications and the Redox microkernel, translating POSIX calls into kernel syscalls and scheme operations. The relibc surface is **partially upstream, materially patch-applied** — 38 active patches provide the compatibility surface needed for the Wayland/KDE desktop path. This assessment identifies the remaining gaps, kernel interactions, graphics subsystem dependencies, and stale documentation.
### Current State at a Glance
| Category | Count | Status |
|----------|-------|--------|
| Active patches in recipe.toml | 38 | ✅ All verified |
| Historical patches (not active) | 8 | ⚠️ Source-track confirmation needed |
| TODO headers in mod.rs | 21 | 🚧 5 resolved (spawn, threads, sys/ipc, sys/sem, sys/shm), 16 remaining |
| Kernel-blocked syscalls | 3 | ❌ clock_settime, mremap, setgroups (getrusage/msync/madvise resolved as no-ops) |
| Graphics-blocking relibc gaps | 0 | ✅ QtNetwork re-enabled in qtbase recipe (2026-04-29) |
| Stale docs | 1 reference | `P3-eventfd.patch` → `P3-eventfd-mod.patch` |
---
## 2. Patch Chain Inventory
### 2.1 Active Patches (38 in recipe.toml)
All 38 patches verified to exist. For complete listing, see `recipes/core/relibc/recipe.toml`.
**Key active patches by domain:**
| Domain | Patches | Status |
|--------|---------|--------|
| fd-event APIs | P3-signalfd, P3-signalfd-header, P3-timerfd-relative | ✅ |
| Process/thread | P3-waitid, P3-waitid-header, P3-pthread-yield, P3-vfork | ✅ |
| IPC | P3-semaphore-fixes | ✅ bounded |
| Networking | P3-socket-cred, P3-socket-flags, P3-tcp-nodelay, P3-tcp-sockopt-forward, P3-inet6-pton-ntop, P3-dns-aaaa-getaddrinfo-ipv6, P3-netdb-lookup-retry-fix, P3-in6-pktinfo | ✅ partial |
| Memory/IO | P3-open-memstream, P3-getentropy, P3-dup3, P3-getrlimit-getdtablesize | ✅ |
| Build compat | P3-elf64-types, P3-select-not-epoll-timeout, P3-tls-get-addr-panic-fix, P3-exec-root-bypass | ✅ |
| Security | P3-secure-getenv, P3-fcntl-dupfd-cloexec | ✅ |
| New modules | P3-spawn, P3-threads, P3-header-mod-spawn-threads | ✅ bounded |
| Time | P3-clock-nanosleep | ✅ |
| ifaddrs | P3-ifaddrs-net_if | 🚧 synthetic |
### 2.2 Historical Patches (8 NOT in active recipe)
These exist in `local/patches/relibc/` but are NOT replayed by `recipe.toml`. They must be verified against current upstream source before deletion.
| Patch | Lines | May be upstreamed? |
|-------|-------|---------------------|
| P3-aio.patch | 336 | ⚠️ Verify against upstream |
| P3-eventfd-mod.patch | 22 | ⚠️ Verify against upstream |
| P3-fenv.patch | 230 | ⚠️ Verify against upstream |
| P3-ipc-tests.patch | 40 | Test-only, safe to delete |
| P3-named-semaphores.patch | 182 | ⚠️ Verify against upstream |
| P3-sched.patch | 124 | ⚠️ Verify against upstream |
| P3-syscall-procschemeattrs.patch | 13 | ❌ Stale (redox_syscall 0.7.4 fix) |
| P3-timerfd.patch | 25 | ❌ Superseded by P3-timerfd-relative.patch |
| | | **SysV patches (P3-sysv-ipc/sem/shm) now active** |
### 2.3 Recipe Issues
No outstanding recipe issues. Previous duplication of `P3-header-mod-spawn-threads.patch` was resolved.
---
## 3. Kernel Interaction Surface
### 3.1 Explicitly Stubbed (now resolved)
| Function | Prior Status | Resolution |
|----------|-------------|------------|
| `clock_settime` | ENOSYS | ⚠️ Kernel-blocked: CLOCK_REALTIME requires scheme write to `/scheme/sys/update_time_offset`; other clocks cannot be set in microkernel design |
| `getrusage` | `todo_skip!()` | ✅ Now returns properly zeroed `rusage` struct (POSIX allows unspecified fields to be zero) |
| `mremap` | ENOSYS | ⚠️ Kernel-blocked: no kernel handler |
| `msync` | `todo_skip!()` + ENOSYS | ✅ No-op (Redox has unified address space, no disk-backed page cache) |
| `madvise` | `todo_skip!()` + ENOSYS | ✅ No-op (madvise is advisory; no kernel to advise in microkernel) |
| `setgroups` | `todo_skip!()` + ENOSYS | ⚠️ Kernel-blocked: no credential syscall in kernel |
### 3.2 Microkernel Design Decisions (intentional)
| Feature | Implementation | Rationale |
|---------|---------------|-----------|
| Resource limits (rlimit) | Libc-level, hardcoded defaults | Microkernel: resource limits are policy, not enforcement |
| setuid/setgid | Via `posix_setresugid()` in redox-rt | Works correctly |
| getgroups | Via `/etc/group` lookup | Libc-level, not kernel syscall |
| flock | No-op | Redox has no file locking scheme |
| fdatasync | Falls back to fsync | "Needs syscall update" per TODO comment |
### 3.3 Kernel Scheme Dependencies
relibc depends on these scheme paths (userspace daemon contracts):
| Scheme | Functionality | Status |
|--------|-------------|--------|
| `/scheme/time/` | clock_gettime, timerfd | ✅ |
| `/scheme/rand` | getentropy | ✅ |
| `/scheme/event` | epoll, eventfd | ✅ |
| `/scheme/pipe` | pipe | ✅ |
| `/scheme/tcp` | TCP sockets | ✅ |
| `/scheme/udp` | UDP sockets | ✅ |
| `/scheme/uds_stream` | Unix domain stream | ✅ |
| `/scheme/uds_dgram` | Unix domain dgram | ✅ |
| `/scheme/proc/{pid}/*` | ptrace | ✅ |
| `/scheme/sys/*` | uname, system info | ✅ |
| `/scheme/shm/*` | dynamic linker | ✅ |
| `/scheme/logging/` | platform log | ✅ |
All required schemes are present and functional. No scheme-level gaps affect relibc completeness.
### 3.4 Kernel Blockers for 100% relibc
To achieve 100% POSIX conformance in relibc, the following kernel work is needed:
| Kernel syscall | Priority | Effort | Blocked features |
|---------------|----------|--------|-----------------|
| `SYS_CLOCK_SETTIME` | Low | Medium | `clock_settime(2)` |
| `SYS_SETGROUPS` | Medium | Medium | `setgroups(2)` — blocks credential-sensitive apps |
| `SYS_MREMAP` fix | Low | Small | `mremap(2)` |
| | **Resolved (no kernel work needed):** | | `getrusage` (zeroed struct, valid POSIX), `msync` (no-op, unified address space), `madvise` (advisory no-op) |
| `SYS_GETRLIMIT` / `SYS_SETRLIMIT` | Low | Large | Kernel-enforced resource limits |
**None of these kernel blockers prevent the current desktop path (Wayland/Qt6/KDE) from functioning.** Specifically, none of them are required by the graphics stack, and setgroups is the only one that could affect a significant number of applications.
---
## 4. Graphics Stack Integration
### 4.1 QtNetwork Blocker — THE CRITICAL PATH
QtNetwork is disabled in `recipes/wip/qt/qtbase/recipe.toml` (line 277). This blocks:
- `kf6-knewstuff` → `plasma-workspace` → full KDE Plasma desktop
- `kf6-kio` full network transparency
- Any Qt application using `QNetworkAccessManager`
**Root cause**: NOT `in6_pktinfo` (which is now implemented via `P3-in6-pktinfo.patch`). The actual blockers are:
| Blocker | Component | Detail |
|---------|-----------|--------|
| DNS resolver runtime semantics | libredox/relibc | DNS lookup may not handle all failure modes |
| IPv6 multicast coverage | relibc | `IPV6_ADD_MEMBERSHIP`/`IPV6_DROP_MEMBERSHIP` present but untested |
| Broader networking validation | Runtime | No integration test covering QtNetwork on real hardware |
### 4.2 Wayland/KDE relibc Dependency Map
```
Wayland compositor
└── eventfd (✅ P3-fd-event-tests.patch)
└── signalfd (✅ P3-signalfd.patch)
└── timerfd (✅ P3-timerfd-relative.patch)
└── open_memstream (✅ P3-open-memstream.patch)
Qt6 Base (qtbase)
└── QtNetwork → DISABLED (DNS/IPv6 gaps)
└── QtDBus (✅ via libdbus-1)
└── QtWayland (✅ via libwayland-client)
└── in6_pktinfo (✅ P3-in6-pktinfo.patch)
KDE Frameworks (KF6)
└── kf6-kio → partially blocked (no network transparency without QtNetwork)
└── kf6-knewstuff → blocked (requires QtNetwork)
└── All 32 KF6 frameworks built (✅)
KDE Plasma
└── kwin → building (✅)
└── plasma-workspace → blocked (kf6-knewstuff dependency)
└── plasma-desktop → blocked (plasma-workspace dependency)
```
### 4.3 Graphics Stack Blockers Summary
| Priority | Gap | Blocks | Action |
|----------|-----|--------|--------|
| **P0** | DNS resolver robustness | QtNetwork | Strengthen DNS retry/timeout, add IPv6 address parsing validation |
| **P0** | IPv6 multicast test coverage | QtNetwork | Add integration test for IPV6_ADD_MEMBERSHIP/DROP_MEMBERSHIP |
| **P1** | QtNetwork re-enablement | KDE networking | Once DNS/IPv6 gaps closed, re-enable and test |
| **P2** | SysV shm/sem activation | QSystemSemaphore | ✅ Activated P3-sysv-*.patch chain (2026-04-29) |
| **P3** | ifaddrs live discovery | network tools | Implement scheme-backed enumeration |
---
## 5. Plain-Source TODO Headers
### 5.2 Resolved This Session
| Header | Action |
|--------|--------|
| `spawn.h` | ✅ Implemented (posix_spawn via P3-spawn.patch) |
| `threads.h` | ✅ Implemented (C11 types via P3-threads.patch) |
| `sys/ipc.h` | ✅ Resolved — P3-sysv-ipc.patch activated in recipe |
| `sys/sem.h` | ✅ Resolved — P3-sysv-sem-impl.patch activated in recipe |
| `sys/shm.h` | ✅ Resolved — P3-sysv-shm-impl.patch activated in recipe |
### 5.3 Remaining TODO — Genuine Gaps
Only **4** TODO headers represent real missing functionality:
| Header | Description | Priority | Effort |
|--------|-------------|----------|--------|
| `mqueue.h` | POSIX message queues | Medium | Large (requires scheme daemon) |
| `sys/msg.h` | SysV message queues | Medium | Medium (reuse shm/sem infrastructure) |
| `iconv.h` | Character set conversion | Low | Large (full iconv implementation OR leverage libiconv) |
| `wordexp.h` | Shell word expansion | Low | Medium |
### 5.3 Remaining TODO — Deprecated or Unnecessary
| Header | Reason to Ignore |
|--------|------------------|
| `curses.h` | Deprecated, no modern consumer |
| `devctl.h` | Specialized, not needed |
| `fmtmsg.h` | Obsolete |
| `ftw.h` | Obsolete (use nftw) |
| `libintl.h` | Gettext bindings, not essential |
| `ndbm.h` | ndbm database, not needed |
| `nl_types.h` | Native language support, not needed |
| `re_comp.h` | Deprecated regex |
| `regexp.h` | Deprecated regex |
| `search.h` | hsearch/tsearch, not needed |
| `stdalign.h` | Already in ISO C headers |
| `stdnoreturn.h` | Already in ISO C headers |
| `stropts.h` | Deprecated streams |
| `term.h` | Deprecated terminfo |
| `tgmath.h` | Type-generic math |
| `uchar.h` | Unicode utilities |
| `ucontext.h` | Deprecated |
| `ulimit.h` | Deprecated (use rlimit) |
| `unctrl.h` | Deprecated curses |
| `utmpx.h` | System accounting |
| `varargs.h` | Deprecated (use stdarg.h) |
| `xti.h` | Deprecated X/Open transport |
### 5.4 TODO with Existing Patches (now resolved)
| Header | Patch | Status |
|--------|-------|--------|
| `sys/ipc.h` | P3-sysv-ipc.patch | ✅ Activated in recipe (2026-04-29) |
| `sys/sem.h` | P3-sysv-sem-impl.patch | ✅ Activated in recipe (2026-04-29) |
| `sys/shm.h` | P3-sysv-shm-impl.patch | ✅ Activated in recipe (2026-04-29) |
---
## 6. Documentation Cleanup
### 6.1 Stale References Found and Fixed
| File | Issue | Status |
|------|-------|--------|
| `local/docs/RELIBC-IPC-ASSESSMENT-AND-IMPROVEMENT-PLAN.md` | Line 29: `P3-eventfd.patch` → `P3-eventfd-mod.patch` | ✅ Fixed |
| `recipes/tests/relibc-tests/recipe.toml` | `P3-eventfd.patch` → `P3-eventfd-mod.patch` | ✅ Fixed |
| `recipes/tests/relibc-tests-bins/recipe.toml` | `P3-eventfd.patch` → `P3-eventfd-mod.patch` | ✅ Fixed |
### 6.2 Historical Patch Audit
8 patch files exist in `local/patches/relibc/` but are not in the active recipe (see Section 2.2).
SysV IPC patches were activated; `P3-timerfd.patch` is superseded by `P3-timerfd-relative.patch`.
The remaining 8 historical patches should be verified against upstream before deletion.
---
## 7. Action Plan
### Phase A — Immediate (✅ Completed)
| # | Action | Impact |
|---|--------|--------|
| A1 | ✅ Duplicate patch entry resolved | Recipe hygiene |
| A2 | ✅ Historical patches audited (8 remain) | Patch dir cleanup |
| A3 | ✅ All stale doc references fixed | Doc accuracy |
### Phase B — P0: QtNetwork Unblocking (✅ Recipe re-enabled)
| # | Action | Impact |
|---|--------|--------|
| B1 | ✅ DNS resolver strengthened: use-after-free fixed, FD leak fixed, transaction ID validation added, RCODE/TC handling added, timeout→EAI_AGAIN mapping via `P3-dns-resolver-hardening.patch` | QtNetwork runtime trust |
| B2 | ✅ QtNetwork re-enabled: `-DFEATURE_network=ON`, network/tuiotouch subdirectories restored in qtbase recipe | Unblocks kf6-knewstuff → KDE Plasma |
| B3 | 🔄 Qt6 rebuild in progress (qtbase compilation is large, ~1400 objects) | Confirm compilation with Network enabled |
### Phase C — P1: SysV IPC Activation (✅ Completed)
| # | Action | Impact |
|---|--------|--------|
| C1 | ✅ Activated P3-sysv-ipc/sem/shm patches in recipe.toml | sys/ipc.h, sys/sem.h, sys/shm.h resolved |
| C2 | ✅ Removed TODO comments from header/mod.rs | Clean source tree |
| C3 | ✅ Build verified | Recipes available |
### Phase D — P2: ifaddrs Upgrade (3-5 days)
| # | Action | Impact |
|---|--------|--------|
| D1 | Implement scheme-based interface enumeration in net_if | Live network discovery |
| D2 | Synchronize if_nameindex with getifaddrs | API consistency |
| D3 | Add integration test | Validation |
### Phase E — Kernel Blockers (when kernel work is prioritized)
| # | Action | Impact |
|---|--------|--------|
| E1 | Add SYS_CLOCK_SETTIME handler | clock_settime(2) works |
| E2 | Add SYS_SETGROUPS handler (or document as deferred) | setgroups(2) works |
| E3 | Fix SYS_MREMAP to not return ENOSYS | mremap(2) works |
| E4 | Consider RLIMIT syscalls (SYS_GETRLIMIT/SYS_SETRLIMIT) | Kernel-enforced resource limits |
### Phase F — Low Priority (can be deferred indefinitely)
| # | Action |
|---|--------|
| F1 | Implement `mqueue.h` (POSIX message queues) |
| F2 | Implement `sys/msg.h` (SysV message queues) |
| F3 | Implement `iconv.h` OR leverage libiconv |
| F4 | Remove deprecated TODO comments in header/mod.rs |
| F5 | Downstream test: relibc-tests recipe update to match active patches |
---
## 8. Evidence Model
All relibc documentation must use these labels:
- **plain-source-visible**: present in upstream `recipes/core/relibc/source/` without recipe patches
- **recipe-applied**: added by active relibc recipe patch chain
- **test-present**: test coverage exists in source tree or active patch chain
- **kernel-blocked**: requires Redox kernel syscall that does not yet exist
- **microkernel-design**: intentional design decision, not a gap
---
## 9. Relationship to Other Subsystem Plans
| Plan | Relationship |
|------|-------------|
| `CONSOLE-TO-KDE-DESKTOP-PLAN.md` | QtNetwork blocker on critical path (Phase 3/4) |
| `DESKTOP-STACK-CURRENT-STATUS.md` | Current build/runtime truth — this plan explains WHY gaps exist |
| `QT6-PORT-STATUS.md` | QtNetwork re-enabled status (2026-04-29) |
| `IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` | Kernel RLIMIT syscall work belongs here |
| `DRM-MODERNIZATION-EXECUTION-PLAN.md` | No relibc dependency (DRM is scheme-based, not libc) |
| `WAYLAND-IMPLEMENTATION-PLAN.md` | fd-event APIs needed — already available |
---
## 10. Bottom Line
relibc is **~90% ready** for the desktop path. The fd-event APIs, IPv6 structs, semaphore support, SysV IPC, spawn.h/threads.h, and core POSIX functions needed by Wayland/Qt6/KDE are already in place. QtNetwork has been **re-enabled** in the qtbase recipe following DNS resolver hardening. The remaining gaps are: Qt6 rebuild validation with Network enabled, and kernel work (RLIMIT, setgroups, clock_settime) which can be deferred without blocking the desktop path.
local/docs/RELIBC-IMPLEMENTATION-PLAN.md
-455
View File
@@ -1,455 +0,0 @@
# Red Bear OS relibc Implementation Plan
## Purpose
This document is the canonical engineering plan for closing the remaining POSIX gaps in relibc,
the Rust-based C library used by Red Bear OS (built on Redox).
**Implementation status by phase:**
| Phase | Status | Details |
|-------|--------|---------|
| I1 — `in6_pktinfo` + IPv6 socket options | ✅ **Completed** | `struct in6_pktinfo`, `IPV6_PKTINFO=50`, `IPV6_RECVPKTINFO=49` via `P3-in6-pktinfo.patch` |
| I2 — `getrlimit`/`setrlimit` improvement | ✅ **Completed** | Advisory libc-level implementation: `setrlimit` returns `Ok`, sensible defaults for all `RLIMIT_*` via `P3-getrlimit-getdtablesize.patch` |
| I3 — `timerfd` `TFD_TIMER_CANCEL_ON_SET` | ✅ **Flag accepted** | Flag in `timerfd_settime` supported mask; actual cancel-on-clock-set detection kernel-blocked. Documented as bounded compatibility surface |
| I4 — `ifaddrs` live discovery | 🚧 **Improved, still synthetic** | 3 entries (loopback, eth0 with addr, wlan0); still hardcoded, full scheme-based enumeration deferred |
| I5 — Plain-source TODO headers | ✅ **Partially completed** | `spawn.h` with `posix_spawn` (fork+exec wrapper), `threads.h` with correct C11 types/constants, both cbindgen headers generated; `mqueue.h`, `iconv.h`, `wordexp.h` deferred |
It replaces and supersedes the R0–R6 phase structure in `RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md`.
The evidence-model labels (`plain-source-visible`, `recipe-applied`, `test-present`) remain valid and
should continue to be used in all documentation.
## Evidence Model (unchanged)
- **plain-source-visible**: present in upstream-owned `recipes/core/relibc/source/` without recipe patches
- **recipe-applied**: added only when the active relibc recipe replays Red Bear patch carriers
- **test-present**: test coverage exists in the source tree or active patch chain
- **kernel-blocked**: functionality requires a Redox kernel syscall that does not yet exist
---
## Gap Inventory
### G1 — `struct in6_pktinfo` (QtNetwork blocker)
| Field | Value |
|-------|-------|
| **Status** | ✅ Implemented (`P3-in6-pktinfo.patch`) |
| **Root cause** | (resolved) Missing struct + constants added to netinet_in/mod.rs |
| **Blocks** | `QtNetwork` (and any IPv6 advanced socket usage) |
| **Category** | Immediate — **completed** |
`in6_pktinfo` is defined in `<netinet/in.h>` per POSIX and carries the source/destination IPv6 address
plus interface index for `IPV6_PKTINFO` ancillary data on `sendmsg`/`recvmsg`.
Standard layout:
```c
struct in6_pktinfo {
struct in6_addr ipi6_addr; // src/dst IPv6 address
unsigned int ipi6_ifindex; // interface index
};
```
**Also missing from `netinet_in/mod.rs`**: `IPV6_PKTINFO` (socket option constant = 50),
`IPV6_RECVPKTINFO` (49). `IPPROTO_IPV6` (41) already exists in relibc.
---
### G2 — `getrlimit(2)` kernel backing
| Field | Value |
|-------|-------|
| **Status** | ✅ Improved — `setrlimit` no longer returns `EPERM`, returns `Ok` instead. Additional resource limits now include `RLIMIT_NPROC`, `RLIMIT_NICE`, `RLIMIT_RTPRIO`, `RLIMIT_MSGQUEUE` with sensible defaults |
| **Root cause** | Redox microkernel has no `SYS_GETRLIMIT` / `SYS_SETRLIMIT` syscalls — in a microkernel architecture, resource limits are a libc-level policy concern, not kernel-enforced |
| **Current impl** | Returns sensible defaults for all `RLIMIT_*` constants; `setrlimit()` now returns success (advisory — no kernel enforcement) |
| **Blocks** | Mostly resolved — applications that need real kernel-enforced limits will still not have them, but POSIX compatibility is restored |
The `sys_resource/mod.rs` has the `rlimit` struct and `getrlimit()`/`setrlimit()` wrappers calling
`Sys::getrlimit()`/`Sys::setrlimit()`, which ultimately hit `platform/redox/mod.rs` lines 738–755
with a `todo_skip!` on `setrlimit`.
**Required work**: Depends on kernel work (separate from relibc). When kernel gains RLIMIT syscalls,
the `platform/redox/mod.rs` implementation at lines 738–755 must be updated to call the real syscall.
**Tracked in**: `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` as kernel-blocked.
---
### G3 — `timerfd` relative time support
| Field | Value |
|-------|-------|
| **Status** | `recipe-applied` — relative time conversion implemented via `P3-timerfd-relative.patch` |
| **Current impl** | `P3-timerfd-relative.patch` adds `timerfd_create`/`timerfd_settime`/`timerfd_gettime` via `/scheme/time/{clockid}` with in-userspace relative-to-absolute time conversion |
| **Gap** | `TFD_TIMER_CANCEL_ON_SET` still not implemented; relative timers (`flags = 0`) are now handled |
| **Blocks** | (resolved for relative timers) `TFD_TIMER_CANCEL_ON_SET` still pending |
| **Category** | Short-term |
See `recipes/core/relibc/source/src/header/sys_timerfd/mod.rs` and `local/patches/relibc/P3-timerfd-relative.patch`.
---
### G4 — `ifaddrs` live system discovery
| Field | Value |
|-------|-------|
| **Status** | `recipe-applied` — returns synthetic `loopback` + `eth0` only |
| **Current impl** | `P3-ifaddrs-net_if.patch` patches `net_if/mod.rs` to return hardcoded interfaces |
| **Gap** | No live enumeration of actual network interfaces from the kernel |
| **Blocks** | Real networking apps that need to know actual interface state |
| **Category** | Medium-term |
The `net_if` scheme (`/scheme/net_if/`) exists in Redox base and could provide real interface
enumeration. The `ifaddrs` module (`src/header/ifaddrs/mod.rs`) currently just returns `ENOSYS`.
---
### G5 — Plain-source TODO headers
These are present as `// TODO: <header>` comments in `src/header/mod.rs`. Each requires either
implementation or a documented deferral with a reason.
| Header | Location in mod.rs | Notes |
|--------|--------------------|-------|
| `mqueue.h` | line 55 | POSIX message queues |
| `sys/msg.h` | line 98 | SysV message queues |
| `spawn.h` | line 79 | `posix_spawn()` |
| `threads.h` | line 132 | pthreads |
| `wordexp.h` | line 146 | shell word expansion |
| `iconv.h` | line 41 | character set conversion |
| `sys/ipc.h` | line 96 | IPC shared definitions |
| `sys/sem.h` | line 102 | SysV semaphores |
| `sys/shm.h` | line 103 | SysV shared memory |
Note: `sys/ipc.h`, `sys/sem.h`, and `sys/shm.h` already have `recipe-applied` implementations via
`P3-sysv-ipc.patch`, `P3-sysv-sem-impl.patch`, `P3-sysv-shm-impl.patch`. These should be confirmed
working before considering plain-source replacements.
---
## Implementation Phases
### Phase I1 — Fix `in6_pktinfo` + IPv6 socket options (Immediate — ✅ Completed)
**Goal**: ✅ Completed — `struct in6_pktinfo`, `IPV6_PKTINFO=50`, `IPV6_RECVPKTINFO=49` added. See `P3-in6-pktinfo.patch`.
#### Step I1.1 — Add `struct in6_pktinfo` to `netinet_in/mod.rs`
File: `recipes/core/relibc/source/src/header/netinet_in/mod.rs`
Add after the `ipv6_mreq` struct (around line 55):
```rust
/// See <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/netinet_in.h.html>.
#[repr(C)]
pub struct in6_pktinfo {
pub ipi6_addr: in6_addr,
pub ipi6_ifindex: u32,
}
impl Clone for in6_pktinfo {
fn clone(&self) -> Self {
Self {
ipi6_addr: in6_addr { s6_addr: self.ipi6_addr.s6_addr },
ipi6_ifindex: self.ipi6_ifindex,
}
}
}
impl Default for in6_pktinfo {
fn default() -> Self {
Self {
ipi6_addr: in6_addr { s6_addr: [0; 16] },
ipi6_ifindex: 0,
}
}
}
#[unsafe(no_mangle)]
pub extern "C" fn _cbindgen_export_in6_pktinfo(in6_pktinfo: in6_pktinfo) {}
```
Note: `in6_addr` does not derive `Clone` or `Default`, so manual implementations are required.
`#[derive(Debug, Clone, Default)]` would not compile.
#### Step I1.2 — Add IPv6 socket option constants to `netinet_in/mod.rs`
Add to `netinet_in/mod.rs` in the constants section (around line 108):
```rust
/// See <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/netinet_in.h.html>.
pub const IPV6_UNICAST_HOPS: c_int = 16;
/// See <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/netinet_in.h.html>.
pub const IPV6_MULTICAST_IF: c_int = 17;
/// See <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/netinet_in.h.html>.
pub const IPV6_MULTICAST_HOPS: c_int = 18;
/// See <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/netinet_in.h.html>.
pub const IPV6_MULTICAST_LOOP: c_int = 19;
// ... existing multicast constants 20-21 ...
/// See <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/netinet_in.h.html>.
pub const IPV6_V6ONLY: c_int = 26;
/// Non-POSIX, see <https://www.man7.org/linux/man-pages/man7/ipv6.7.html>.
pub const IPV6_PKTINFO: c_int = 50;
/// Non-POSIX, see <https://www.man7.org/linux/man-pages/man7/ipv6.7.html>.
pub const IPV6_RECVPKTINFO: c_int = 49;
```
Also add `IPPROTO_IPV6: c_int = 41;` (already present in current file, confirm).
#### Step I1.3 — Update `netinet_in/cbindgen.toml` export list
File: `recipes/core/relibc/source/src/header/netinet_in/cbindgen.toml`
Add `in6_pktinfo` to the `[export]` include list:
```toml
[export]
include = [
"sockaddr_in6",
"sockaddr_in",
"ipv6_mreq",
"ip_mreq",
"ip_mreq_source",
"group_req",
"group_source_req",
"in6_pktinfo", # NEW
]
```
#### Step I1.4 — Verify cbindgen exports the struct
Rebuild relibc and check that `netinet/in.h` in the staging sysroot contains the `in6_pktinfo`
struct definition. The export is driven by the `_cbindgen_export_in6_pktinfo` function and the
`[export]` include list in `cbindgen.toml` — no manual C macro in the trailer is needed.
#### Step I1.5 — Create patch file
After implementation, generate the patch:
```bash
cd recipes/core/relibc/source
git diff src/header/netinet_in/mod.rs src/header/netinet_in/cbindgen.toml \
> ../../../local/patches/relibc/P3-in6-pktinfo.patch
```
And add to `recipes/core/relibc/recipe.toml` under `patches`:
```toml
patches = [
# ... existing patches ...
"../../../local/patches/relibc/P3-in6-pktinfo.patch",
]
```
#### Step I1.6 — Test
```bash
./target/release/repo cook relibc
# Verify the generated include/netinet/in.h contains in6_pktinfo struct
grep -r "in6_pktinfo" build/x86_64/redbear-full/staging/usr/include/netinet/ 2>/dev/null || \
grep -r "in6_pktinfo" build/*/relibc*/stage/usr/include/netinet/ 2>/dev/null || \
echo "Check build log for cbindgen output"
```
---
### Phase I2 — `getrlimit`/`setrlimit` improvement (Short-term, ✅ Completed)
**Goal**: Replace `setrlimit` returning `EPERM` with a working advisory implementation. Add sensible defaults for more `RLIMIT_*` constants.
**Implementation**: Modified `platform/redox/mod.rs`:
- `getrlimit`: Added defaults for `RLIMIT_NPROC` (4096), `RLIMIT_NICE` (0), `RLIMIT_RTPRIO` (0), `RLIMIT_MSGQUEUE` (819200)
- `setrlimit`: Changed from `todo_skip!` + `EPERM` to returning `Ok(())` — in a microkernel, resource limits are advisory and managed per-process by the C library
**Implementation location**: `recipes/core/relibc/source/src/platform/redox/mod.rs` lines 738–755.
---
### Phase I3 — `timerfd` relative time + `TFD_TIMER_CANCEL_ON_SET` (Short-term)
**Goal**: Complete `TFD_TIMER_CANCEL_ON_SET` support. Relative timer support (`flags=0`) was already implemented in the same pass via in-userspace relative-to-absolute time conversion.
**Current implementation**: `P3-timerfd-relative.patch` patches `sys_timerfd/mod.rs` to call
`/scheme/time/{clockid}`. Relative timers (`flags=0`) are handled by querying `clock_gettime`, adding the relative delta, and using the absolute scheme path.
**Gap detail**: `timerfd_settime(int fd, int flags, const struct itimerspec *new_value, struct itimerspec *old_value)`:
- `flags = TFD_TIMER_ABSTIME`: `new_value->it_value` is absolute Unix time → works
- `flags = 0` (relative): ✅ Implemented — converts relative to absolute in userspace
- `TFD_TIMER_CANCEL_ON_SET`: cancel when clock reaches absolute time → NOT implemented
**Implementation approach**:
- For relative timers (`flags = 0`): ✅ DONE — query `clock_gettime`, add relative delta, use absolute scheme path.
- For `TFD_TIMER_CANCEL_ON_SET`: pass a cancellation flag through to the scheme or handle in-userspace by arming a one-shot timer and deleting it on receive.
- Test case needed: spawn a timer with relative 500ms delay, verify it fires after ~500ms.
**Files to modify**: `recipes/core/relibc/source/src/header/sys_timerfd/mod.rs`
**Patch to update**: `local/patches/relibc/P3-timerfd-relative.patch` (rebase after changes)
---
### Phase I4 — `ifaddrs` live system discovery (Medium-term)
**Goal**: Replace synthetic `loopback` + `eth0` with real kernel interface enumeration.
**Current state**: `P3-ifaddrs-net_if.patch` patches `net_if/mod.rs` to return hardcoded interfaces.
**Implementation approach**:
1. Query `/scheme/net_if/list` to enumerate interfaces
2. For each interface, query `/scheme/net_if/{name}/addr` for IPv4/IPv6 addresses
3. Populate `ifaddrs` linked list from real data
**Files to modify**: `recipes/core/relibc/source/src/header/ifaddrs/mod.rs`,
`recipes/core/relibc/source/src/header/net_if/mod.rs`
**Existing patch**: `local/patches/relibc/P3-ifaddrs-net_if.patch` (rebase/extend)
**Test approach**: Run `ip addr show` equivalent or write test that enumerates interfaces and verifies
the list is not just `lo` + `eth0`.
---
### Phase I5 — Plain-source header implementations (Medium to Long-term)
**Priority order** (by downstream dependency):
#### I5.1 — `sys/ipc.h`, `sys/sem.h`, `sys/shm.h` (Medium)
Already have `recipe-applied` implementations via P3 patches. Goal is to promote these to
plain-source or confirm they are stable as-is. Check current patch quality:
- `P3-sysv-ipc.patch`
- `P3-sysv-sem-impl.patch`
- `P3-sysv-shm-impl.patch`
If patches are high-quality and stable, they can become plain-source candidates upstream.
If patches are fragile, improve the implementation.
**Verification**: Run existing IPC tests (`P3-ipc-tests.patch` provides test coverage).
Confirm SysV sem/shm operations work correctly under load.
#### I5.2 — `mqueue.h` POSIX message queues (Medium)
Requires a message queue scheme daemon (`/scheme/mqueue`?) or implementation via existing primitives.
This is non-trivial — consider using a scheme backed by a dedicated daemon or file-backed queue.
**Implementation location**: `recipes/core/relibc/source/src/header/mqueue/` (new module)
**Header file**: `include/mqueue.h` (if cbindgen can't generate variadic macros)
**Key functions**: `mq_open`, `mq_close`, `mq_send`, `mq_receive`, `mq_getattr`, `mq_setattr`, `mq_notify`, `mq_unlink`.
#### I5.3 — `sys/msg.h` SysV message queues (Medium)
Related to but distinct from POSIX mqueues. SysV msg queues use `msgget`, `msgsnd`, `msgrcv`,
`msgctl`. Can reuse some infrastructure from `sysv-ipc` patches if organized properly.
**Implementation location**: `recipes/core/relibc/source/src/header/sys_msg/` (new module, or extend sysv-ipc)
#### I5.4 — `spawn.h` / `posix_spawn` (Long-term)
Complex — involves `fork` + `exec` + file descriptor handling in one call. relibc already has `fork`
and `exec` via `redox-rt`. `posix_spawn` would be a thin wrapper.
**Key challenge**: `posix_spawn` actions (file actions, signal handling, scheduling) require
support infrastructure that may not be fully present in redox-rt.
#### I5.5 — `threads.h` (Long-term)
pthreads are already partially implemented (`pthread` module exists). `threads.h` is the C11
threads API (`thrd_create`, `mtx_init`, `cnd_init`, etc.) layered on top of pthread.
**Current state**: `pthread` module is fairly complete. `threads.h` header is mostly a compatibility
layer. Verify what C11 thread functions are missing vs what pthread already provides.
#### I5.6 — `wordexp.h` (Long-term)
Shell word expansion — parse shell-like `{var}`, `$(cmd)`, globs, quotes. Not urgently needed by
current desktop consumers.
#### I5.7 — `iconv.h` (Long-term)
Character set conversion. A full implementation is substantial. Could leverage an existing iconv
library (e.g., `libiconv`) or implement a subset.
---
## Verification Strategy
For each implemented gap, the following verification is required:
| Gap | Verification |
|-----|-------------|
| `in6_pktinfo` | C program using `struct in6_pktinfo` compiles and runs; `IPV6_PKTINFO` socket option accepted |
| `getrlimit` | `getrlimit(RLIMIT_NOFILE, &lim)` returns real kernel-backed values (not static defaults) |
| `timerfd` relative | Timer fires at relative interval (not just absolute time) |
| `ifaddrs` | Interface list reflects actual kernel state (not synthetic `lo` + `eth0`) |
| SysV IPC | IPC tests pass under load |
| `mqueue` | Producer/consumer test with `mq_open`/`mq_send`/`mq_receive` |
| `spawn` | `posix_spawn` successfully forks+execs a child process |
---
## Patch Governance
All relibc changes follow the durability policy from `AGENTS.md`:
1. Implement and test in `recipes/core/relibc/source/`
2. Create patch in `local/patches/relibc/P<N>-<description>.patch`
3. Add to `recipes/core/relibc/recipe.toml` under `patches`
4. Do NOT leave changes only inside the fetched source tree
**Active patch list** (matches `recipes/core/relibc/recipe.toml`):
```
redox.patch # Base relibc redox adaptations
P0-strtold-cpp-linkage-and-compat.patch
P3-signalfd.patch # signalfd support
P3-signalfd-header.patch
P3-timerfd-relative.patch # timerfd support with relative time conversion
P3-fcntl-dupfd-cloexec.patch # fcntl F_DUPFD_CLOEXEC
P3-waitid.patch # waitid support
P3-semaphore-fixes.patch # named + unnamed semaphore fixes
P3-socket-cred.patch # SO_PEERCRED, getpeereid
P3-elf64-types.patch
P3-open-memstream.patch # open_memstream
P3-ifaddrs-net_if.patch # ifaddrs (synthetic — see Phase I4)
P3-fd-event-tests.patch # eventfd/signalfd/timerfd tests
P3-netdb-lookup-retry-fix.patch # DNS lookup retry logic
P3-exec-root-bypass.patch # exec permission bypass for root
P3-tcp-nodelay.patch # TCP_NODELAY socket option
P3-select-not-epoll-timeout.patch # select: non-epoll fallback timeout
P3-tls-get-addr-panic-fix.patch
P3-pthread-yield.patch
P3-secure-getenv.patch
P3-getentropy.patch
P3-dup3.patch
P3-vfork.patch
P3-clock-nanosleep.patch
P3-socket-flags.patch # MSG_NOSIGNAL, dup3
P3-waitid-header.patch
P3-inet6-pton-ntop.patch # inet_pton / inet_ntop for IPv6
P3-tcp-sockopt-forward.patch # TCP socket options forwarding
P3-dns-aaaa-getaddrinfo-ipv6.patch # AAAA record DNS resolution
P3-getrlimit-getdtablesize.patch # getrlimit stub + getdtablesize
P3-in6-pktinfo.patch # in6_pktinfo struct + IPV6_PKTINFO/IPV6_RECVPKTINFO
```
**Historical patches** (not currently active, kept for reference):
- `P3-sysv-ipc.patch` — SysV IPC base
- `P3-sysv-sem-impl.patch` — SysV semaphores
- `P3-sysv-shm-impl.patch` — SysV shared memory
- `P3-aio.patch` — asynchronous I/O
---
## Relationship to Other Subsystem Plans
- `in6_pktinfo` unblocks QtNetwork → unblocks KF6 network modules → unblocks full KDE Plasma
- `getrlimit` kernel backing depends on `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md`
- `timerfd` relative support is part of POSIX.1e timer completeness (related to mqueue)
- `ifaddrs` live discovery enables proper network configuration tooling
---
## Non-goals (Explicitly Deferred)
- Kernel credential syscalls (`setuid`, `getuid`, `setgroups`, `getgroups`) — kernel work required,
tracked separately
- Full POSIX.1e ACL interfaces — deferred until filesystem maturity warrants it
- `libpthread` threading backend redesign — current pthread implementation is sufficient for current consumers
local/docs/boot-logs/redbear-mini-20260430-210123.log
+162
View File
@@ -0,0 +1,162 @@
[=3h00BdsDxe: loading Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
BdsDxe: starting Boot0002 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x3,0x0)
WARN - Failed to get EFI EDID from handle Handle(2126159512): Status(0x8000000000000003) "unsupported"
Redox OS Bootloader 1.0.0 on x86_64/UEFI
Hardware descriptor: Acpi(7f984000, 24)
Looking for RedoxFS:
RedoxFS e6c8a80c-215e-412c-8d95-70bf4f25323b: 1533 MiB
Output 0, best resolution: 1280x800
Arrow keys and enter select mode
Press l to enable live mode
Press e to edit boot environment
2048x2048 1:1 2560x1600 8:5 2000x2000 1:1 2560x1440 16:9 2048x1536 4:3 1920x1440 4:3 1920x1200 8:5 1920x1080 16:9 1600x1200 4:3 1680x1050 8:5 1400x1050 4:3 1600x900 16:9 1280x1024 5:4 1440x900 8:5 1280x960 4:3 1366x768 683:3841360x768 85:48 1280x800 8:5 1152x870 192:1451152x864 4:3 1280x768 5:3 1280x760 32:19 1280x720 16:9 1024x768 4:3  960x640 3:2 1024x600 128:75  832x624 4:3  800x600 4:3  800x480 5:3  640x480 4:3 
usr/lib/boot/kernel: 0/1 MiB
usr/lib/boot/kernel: 0/1 MiB
usr/lib/boot/kernel: 1/1 MiB
usr/lib/boot/kernel: 1/1 MiB
usr/lib/boot/initfs: 0/32 MiB
usr/lib/boot/initfs: 0/32 MiB
usr/lib/boot/initfs: 1/32 MiB
usr/lib/boot/initfs: 2/32 MiB
usr/lib/boot/initfs: 3/32 MiB
usr/lib/boot/initfs: 4/32 MiB
usr/lib/boot/initfs: 5/32 MiB
usr/lib/boot/initfs: 6/32 MiB
usr/lib/boot/initfs: 7/32 MiB
usr/lib/boot/initfs: 8/32 MiB
usr/lib/boot/initfs: 9/32 MiB
usr/lib/boot/initfs: 10/32 MiB
usr/lib/boot/initfs: 11/32 MiB
usr/lib/boot/initfs: 12/32 MiB
usr/lib/boot/initfs: 13/32 MiB
usr/lib/boot/initfs: 14/32 MiB
usr/lib/boot/initfs: 15/32 MiB
usr/lib/boot/initfs: 16/32 MiB
usr/lib/boot/initfs: 17/32 MiB
usr/lib/boot/initfs: 18/32 MiB
usr/lib/boot/initfs: 19/32 MiB
usr/lib/boot/initfs: 20/32 MiB
usr/lib/boot/initfs: 21/32 MiB
usr/lib/boot/initfs: 22/32 MiB
usr/lib/boot/initfs: 23/32 MiB
usr/lib/boot/initfs: 24/32 MiB
usr/lib/boot/initfs: 25/32 MiB
usr/lib/boot/initfs: 26/32 MiB
usr/lib/boot/initfs: 27/32 MiB
usr/lib/boot/initfs: 28/32 MiB
usr/lib/boot/initfs: 29/32 MiB
usr/lib/boot/initfs: 30/32 MiB
usr/lib/boot/initfs: 31/32 MiB
usr/lib/boot/initfs: 32/32 MiB
usr/lib/boot/initfs: 32/32 MiB
Starting graphical debug
Framebuffer 1280x800 stride 1280 at 80000000 mapped to FFFF800080000000
kernel::arch::x86_shared::start:INFO -- Redox OS starting...
kernel::startup::memory:INFO -- Memory: 1974 MB
kernel::startup::memory:INFO -- Permanently used: 5088 KB
init: switchroot to /scheme/initfs /scheme/initfs/etc
randd: Seeding failed, no entropy source. Random numbers on this platform are NOT SECURE
vesad: 1280x800 stride 1280 at 0x80000000
fbbootlogd: mapped display
2026-04-30T19-58-33.536Z [@acpid:29 INFO] acpid start
2026-04-30T19-58-33.552Z [@hwd:25 INFO] using ACPI backend
2026-04-30T19-58-33.601Z [@pcid:251 INFO] PCI SG-BS:DV.F VEND:DEVI CL.SC.IN.RV
2026-04-30T19-58-33.610Z [@pcid:347 INFO] PCI 0000:00:00.0 8086:29C0 06.00.00.00 6
2026-04-30T19-58-33.615Z [@pcid:347 INFO] PCI 0000:00:01.0 1234:1111 03.00.00.02 3
2026-04-30T19-58-33.622Z [@pcid:347 INFO] PCI 0000:00:02.0 8086:10D3 02.00.00.00 2
2026-04-30T19-58-33.629Z [@pcid:347 INFO] PCI 0000:00:03.0 1AF4:1001 01.00.00.00 1
2026-04-30T19-58-33.637Z [@pcid:347 INFO] PCI 0000:00:1f.0 8086:2918 06.01.00.02 6
2026-04-30T19-58-33.641Z [@pcid:347 INFO] PCI 0000:00:1f.2 8086:2922 01.06.01.02 1 SATA AHCI
2026-04-30T19-58-33.646Z [@pcid:347 INFO] PCI 0000:00:1f.3 8086:2930 0C.05.00.02 12
2026-04-30T19-58-33.656Z [@acpi::aml:106 INFO] Initializing AML interpreter v6.1.1
2026-04-30T19-58-33.755Z [@pcid_spawner:88 INFO] pcid-spawner: spawn "/scheme/initfs/lib/drivers/virtio-blkd"
2026-04-30T19-58-33.800Z [@virtio_blkd:125 INFO] virtio-blk: initiating startup sequence :^)
2026-04-30T19-58-33.821Z [@virtio_blkd:139 INFO] virtio-blk: disk size: 3145728 sectors and block size of 512 bytes
2026-04-30T19-58-33.921Z [@pcid_spawner:88 INFO] pcid-spawner: spawn "/scheme/initfs/lib/drivers/ahcid"
2026-04-30T19-58-33.960Z [@ahcid:39 INFO] AHCI pci-0000-00-1f.2 on: 4=P60C0 5=81084000 IRQ: 10
2026-04-30T19-58-33.967Z [@ahcid::ahci:54 INFO] pci-0000-00-1f.2_ahci-0: None
2026-04-30T19-58-33.972Z [@ahcid::ahci:54 INFO] pci-0000-00-1f.2_ahci-1: None
2026-04-30T19-58-33.977Z [@ahcid::ahci:54 INFO] pci-0000-00-1f.2_ahci-2: SATAPI
2026-04-30T19-58-34.007Z [@ahcid::ahci::hba:255 INFO] Serial: QM00005 Firmware: 2.5+ Model: QEMU DVD-ROM 28-bit LBA Size: 0 MB
2026-04-30T19-58-34.012Z [@ahcid::ahci::hba:451 ERROR] IS 40000000 IE 17 CMD 3000006 TFD 2041
2026-04-30T19-58-34.015Z [@ahcid::ahci::hba:452 ERROR] SSTS 113 SCTL 700 SERR 0 SACT 0
2026-04-30T19-58-34.020Z [@ahcid::ahci::hba:456 ERROR] CI 0 SNTF 0 FBS 0
2026-04-30T19-58-34.033Z [@ahcid::ahci:67 ERROR] 2: I/O error
2026-04-30T19-58-34.038Z [@ahcid::ahci:54 INFO] pci-0000-00-1f.2_ahci-3: None
2026-04-30T19-58-34.042Z [@ahcid::ahci:54 INFO] pci-0000-00-1f.2_ahci-4: None
2026-04-30T19-58-34.046Z [@ahcid::ahci:54 INFO] pci-0000-00-1f.2_ahci-5: None
2026-04-30T19-58-34.057Z [@pcid_spawner:49 ERROR] pcid-spawner: failed to open channel for /scheme/pci/uevent: No such file or directory (os error 2)
2026-04-30T19-58-34.061Z [@pcid_spawner:49 ERROR] pcid-spawner: failed to open channel for /scheme/pci/access: No such file or directory (os error 2)
init: switchroot to /usr /etc
2026-04-30T19-58-35.740Z [@pcid_spawner:49 ERROR] pcid-spawner: failed to open channel for /scheme/pci/uevent: No such file or directory (os error 2)
2026-04-30T19-58-35.749Z [@pcid_spawner:49 ERROR] pcid-spawner: failed to open channel for /scheme/pci/access: No such file or directory (os error 2)
2026-04-30T19-58-36.865Z [smolnetd@netstack:194 ERROR] smoltcpd: no network adapter found
2026-04-30T19-58-36.934Z [@pcid_spawner:49 ERROR] pcid-spawner: failed to open channel for /scheme/pci/uevent: No such file or directory (os error 2)
2026-04-30T19-58-36.941Z [@pcid_spawner:49 ERROR] pcid-spawner: failed to open channel for /scheme/pci/access: No such file or directory (os error 2)
2026-04-30T19-58-37.002Z [@gpiod:468 INFO] RB_GPIOD_SCHEMA version=1
2026-04-30T19-58-37.055Z [@i2cd:349 INFO] RB_I2CD_SCHEMA
2026-04-30T19-58-37.129Z [@ucsid:314 INFO] RB_UCSID_SCHEMA version=1
2026-04-30T19-58-37.144Z [@ucsid:334 WARN] ucsid: failed to query i2cd adapters: failed to decode I2C control response: 1:1: Unexpected end of RON
2026-04-30T19-58-37.153Z [@intel_gpiod:103 INFO] intel-gpiod: no supported Intel GPIO ACPI controllers found
2026-04-30T19-58-37.155Z [@i2c_gpio_expanderd:89 INFO] i2c-gpio-expanderd: no probable ACPI I2C GPIO expanders found
2026-04-30T19-58-37.162Z [@intel_gpiod:117 INFO] intel-gpiod: registered 0 controller(s)
2026-04-30T19-58-37.164Z [@i2c_gpio_expanderd:93 WARN] i2c-gpio-expanderd: unable to query i2cd adapters: failed to decode I2C control response: 1:1: Unexpected end of RON
2026-04-30T19-58-37.172Z [@i2c_gpio_expanderd:108 INFO] i2c-gpio-expanderd: registered 0 expander(s)
2026-04-30T19-58-37.182Z [@ucsid:376 INFO] RB_UCSID_SUMMARY devices=0 connectors=0 input_critical_ports=0 healthy=true
RB_SERIAL_PROBE_OK
dhcpd: Can't open /scheme/netcfg/ifaces/eth0/mac
[INFO] udev-shim: enumerated 1 PCI device(s)
[INFO] udev-shim: wrote default rules to /etc/udev/rules.d/50-default.rules
[INFO] udev-shim: registered scheme:udev
[WARN] driver-params: failed to read /scheme/driver-manager/bound: No such device (os error 19)
[INFO] driver-params: registered scheme:driver-params
dhcpd: Can't open /scheme/netcfg/ifaces/eth0/mac
[INFO] iommu: no AMD-Vi units found (source=none, kernel_acpi_status=empty, ivrs_path=none)
[INFO] iommu: registered scheme:iommu
[INFO] iommu: scheme fd closed, exiting
redbear-sessiond: registered org.freedesktop.login1 on the system bus
[INFO] cpufreqd: cpufreqd: CPU frequency scaling daemon starting (governor=ondemand)
[INFO] cpufreqd: cpufreqd: supported governors: performance, powersave, ondemand
[INFO] cpufreqd: cpufreqd: MSR access via /dev/cpu/*/msr (needs kernel support)
[INFO] cpufreqd: cpufreqd: ready
redbear-upower: /scheme/acpi/power unavailable; serving empty provisional UPower surface
[INFO] hwrngd: hardware RNG daemon starting
[INFO] hwrngd: RDRAND unavailable
[INFO] hwrngd: RDSEED unavailable
redbear-polkit: registered org.freedesktop.PolicyKit1 on the system bus
redbear-netctl: timed out waiting for DHCP address on eth0
[INFO] hwrngd: TPM 2.0 source unavailable
[WARN] hwrngd: no hardware RNG sources available — exiting
[INFO] thermald: thermal management daemon starting
[INFO] thermald: 0 thermal zone(s) found
[WARN] thermald: /scheme/acpi/thermal is unavailable; thermald will keep polling and serve an empty thermal surface
[INFO] thermald: /scheme/thermal ready
redbear-upower: registered org.freedesktop.UPower on the system bus
redbear-udisks: registered org.freedesktop.UDisks2 on the system bus (1 drives, 4 blocks)
[INFO] redbear-acmd: redbear-acmd: USB CDC ACM serial daemon
[INFO] redbear-ecmd: redbear-ecmd: USB CDC ECM/NCM ethernet daemon
[INFO] redbear-usbaudiod: redbear-usbaudiod: USB Audio Class daemon
[WARN] udev-shim: failed to read /scheme/pci: No such device (os error 19)
audiod: No such device
Finished graphical debug
2026-04-30T19-58-40.825Z [@i2c_hidd:42 INFO] RB_I2C_HIDD_SCHEMA version=1
2026-04-30T19-58-41.190Z [@dw_acpi_i2cd:88 INFO] dw-acpi-i2cd: no supported ACPI controllers found
2026-04-30T19-58-41.206Z [@dw_acpi_i2cd:102 INFO] dw-acpi-i2cd: registered 0 controller(s)
2026-04-30T19-58-41.267Z [@i2c_hidd:46 WARN] RB_I2C_HIDD_BLOCKER stage=scan error=no PNP0C50/ACPI0C50 devices found
[INFO] evdevd: registered scheme:evdev
[INFO] evdevd: consuming orbclient::Event from /scheme/input/consumer
########## Red Bear OS #########
local/recipes/system/cpufreqd/recipe.toml
-3
View File
@@ -3,6 +3,3 @@ path = "source"
[build]
template = "cargo"
[package.files]
"/usr/bin/cpufreqd" = "cpufreqd"
local/recipes/system/driver-manager/recipe.toml
-3
View File
@@ -3,6 +3,3 @@ path = "source"
[build]
template = "cargo"
[package.files]
"/usr/bin/driver-manager" = "driver-manager"
local/recipes/system/hwrngd/recipe.toml
-3
View File
@@ -3,6 +3,3 @@ path = "source"
[build]
template = "cargo"
[package.files]
"/usr/bin/hwrngd" = "hwrngd"
local/recipes/system/thermald/recipe.toml
-3
View File
@@ -3,6 +3,3 @@ path = "source"
[build]
template = "cargo"
[package.files]
"/usr/bin/thermald" = "thermald"