RedBear-OS/docs/07-RED-BEAR-OS-IMPLEMENTATION-PLAN.md

07 — Red Bear OS Implementation Plan

Purpose

This document defines a clear, practical implementation plan for Red Bear OS. It focuses on building a usable, validated system through disciplined packaging, profile-based composition, and incremental hardware enablement, while preserving Redox architecture: userspace drivers, services, and capability-oriented system boundaries.

This is the canonical public plan for how Red Bear OS should evolve at the repository level. Detailed subsystem notes still live in focused documents such as local/docs/AMD-FIRST-INTEGRATION.md, docs/03-WAYLAND-ON-REDOX.md, and docs/05-KDE-PLASMA-ON-REDOX.md.

Core Principles

Preserve the architecture

• Keep drivers and services in userspace.
• Preserve clear system boundaries and capability-based design.
• Stay aligned with upstream Redox where practical.

Packaging is the integration layer

• Deliver functionality as packages and package groups.
• Compose profiles from packages rather than monolithic changes.
• Prefer packaging and configuration work over invasive core-tree rewrites when possible.

Keep Red Bear changes isolated

• Place Red Bear-specific work under local/ whenever possible.
• Keep upstream-facing areas clean and rebase-friendly.
• Use scripts and overlays to make sync/rebase work predictable.

Profiles are products

The supported product surfaces are:

• redbear-minimal
• redbear-desktop
• redbear-full
• redbear-live

Each profile must be buildable, testable, and documented.

Validation over claims

• “Compiles” is not the same as “supported”.
• Every user-visible feature must map to a profile.
• Support status must be explicit, reproducible, and evidence-backed.

System Structure

Layers

1. Upstream platform — Redox kernel, libc, and core services
2. Red Bear integration (local/) — patches, recipes, configs, scripts, overlays
3. Profiles — concrete system builds assembled from packages and package groups

Profiles

redbear-minimal

Console-focused.

• Boot
• Storage
• Package manager
• Wired networking

This is the primary development and validation target.

redbear-desktop

Wayland plus base desktop services.

This is the main integration environment for graphics, input, and desktop bring-up.

redbear-full

KDE Plasma target.

This profile should only include graphics and networking paths that are validated enough to be presented as real user-facing system behavior.

redbear-live

Live, demo, and rescue environment.

This profile should prioritize diagnostics, recovery workflows, and installability.

Packaging Model

Package groups

• base-core
• storage-base
• desktop-base
• wayland-base
• kde-base
• net-base
• net-vm
• net-wired-common
• net-wifi-experimental
• gpu-intel-experimental
• gpu-amd-experimental
• redbear-branding
• redbear-live-tools
• redbear-hwdiag

Rules

• All functionality is delivered via packages.
• Drivers are packaged individually.
• Profiles depend on package groups.
• Package metadata should make support status obvious.

Workstreams

1. Repository discipline

Define and maintain contribution rules.

• Keep all custom work under local/ where possible.
• Provide scripts for rebasing, diffing, and resyncing upstream.
• Make repository governance visible and repeatable.

Outputs

• local/docs/repo-governance.md
• Maintenance scripts

Acceptance

• Custom work is easy to identify.
• Upstream sync work is predictable and documented.

2. Profiles and packaging

Formalize profile definitions and package-group composition.

• Map each profile to package groups.
• Standardize package metadata and support labeling.
• Keep profile behavior reproducible.

Acceptance

• Profiles are reproducible and documented.

3. Driver substrate

Implement and stabilize the shared driver base.

• redox-driver-sys for shared driver plumbing
• PCI, MMIO, IRQ, and DMA support
• Driver daemon template for new device work

Acceptance

• A new driver can be created from a known template.

4. Graphics and Wayland

Drive the graphical stack through concrete milestones.

Milestones

• Run one Wayland application
• Start KWin
• Launch Plasma shell

Acceptance

• At least one profile runs a real graphical session.

5. Networking

Architecture

• Per-NIC driver daemons
• Network service for interfaces, DHCP, and routing
• D-Bus compatibility surface where desktop software expects it

Milestones

N1: VM networking

• virtio-net
• DHCP and package access

N2: Wired hardware

• Intel NICs
• Realtek NICs

N3: KDE integration

• NetworkManager-compatible D-Bus subset

N4: Wi-Fi (experimental)

• Single chipset family first

Acceptance

• Wired networking works in at least one real profile.

6. KDE integration

• Package the D-Bus session path
• Provide a networking shim where KDE expects one
• Provide an audio compatibility layer where needed
• Package session startup and startup dependencies

Acceptance

• A KDE session launches and its limitations are documented.

7. Live image and diagnostics

• Hardware detection tools
• Network diagnostics
• Graphics diagnostics

Acceptance

• The live image can diagnose common failure cases.

8. Validation and CI

Support labels

• builds
• boots
• network
• wayland
• kde
• validated
• experimental

Tasks

• VM-based tests
• Hardware validation matrix

Acceptance

• Support status is explicit and reproducible.

Development Phases

Phase A — Structure

• Repository rules
• Profile definitions

Phase B — Minimal system

• Boot
• Package management
• VM networking

Phase C — Driver base

• Shared driver layer

Phase D — Graphics

• Wayland
• Qt application bring-up

Phase E — Networking

• Wired networking
• KDE-visible networking path

Phase F — Desktop

• KDE session becomes usable

Phase G — Hardware validation

• One fully validated profile

Phase H — Wi-Fi

• Experimental expansion

Task Template

Every substantial work item should capture:

• Title
• Objective
• Scope
• Files affected
• Dependencies
• Implementation notes
• Acceptance criteria
• Validation steps
• Risks

Final Direction

Red Bear OS should evolve as a profile-driven, package-defined system built on Redox architecture. Progress should be measured by working profiles, not theoretical completeness.

Priority order

1. Repository discipline
2. Profile reproducibility
3. VM usability
4. Graphics bring-up
5. Wired networking
6. KDE integration
7. Hardware validation
8. Wi-Fi expansion

Related Documents

• Root README
• Architecture Overview
• Gap Analysis & Roadmap
• Wayland on Redox
• Linux Driver Compatibility Layer
• KDE Plasma on Redox
• local/docs/AMD-FIRST-INTEGRATION.md