vasilito 5d06b0fa03 quirks: ACPI DMI infrastructure (R11 part 1)
Phase R11 (2026-06-07) — ACPI DMI rules first commit. Lands
the infrastructure pieces (flag type, rule struct,
TOML parser, lookup function) needed for runtime ACPI
quirk matching against system DMI data. The data side
arrives in the follow-up commit (four quirks.d/*.toml
files).

Changes:

  1. AcpiQuirkFlags bitflags (mod.rs:225) with 13 bits
     sourced from Linux 7.1:
       OSI_DISABLE_{LINUX,VISTA,WIN7,WIN8}  — drivers/acpi/osi.c
       SLEEP_{OLD_ORDERING,NVS_NOSAVE,DEFAULT_S3} — drivers/acpi/sleep.c
       LID_INIT_{DISABLED,OPEN}              — drivers/acpi/button.c
       BATTERY_{BIX_BROKEN_PACKAGE,
                 NOTIFICATION_DELAY,
                 AC_IS_BROKEN}                — drivers/acpi/battery.c
       REV_OVERRIDE                          — drivers/acpi/x86/blacklist.c

  2. DmiAcpiQuirkRule (dmi.rs:476) — DMI match + flag word,
     mirrors the existing DmiXhciQuirkRule shape.

  3. DMI_ACPI_QUIRK_RULES — empty compiled-in table for now;
     runtime TOML is the data surface (R11 part 2). The
     constant exists so the three-layer lookup shape is
     stable from day one.

  4. load_dmi_acpi_quirks() — reads live SMBIOS, applies
     compiled-in + TOML rules, returns AcpiQuirkFlags.
     Pattern mirrors load_dmi_xhci_quirks (R7-B).

  5. apply_dmi_acpi_quirk_rules() — pure function, OR-
     accumulates matching rules. Mirrors
     apply_dmi_xhci_quirk_rules.

  6. ACPI_FLAG_NAMES + parse_dmi_acpi_toml + load_dmi_acpi_quirks
     in toml_loader.rs. New TOML table type
     [[dmi_acpi_quirk]] with  sub-table +
     array of strings.

  7. Two unit tests in dmi.rs: empty result for no match,
     OR-accumulation for partial match (one rule fires
     one flag, the other fires another — both must land).

cargo test: 122/122 (was 120, +2 for the new tests).
cargo check: clean.
cargo clippy: no new warnings in this code.

The data side (46-acpi-sleep.toml, 47-acpi-button.toml,
48-acpi-battery.toml) lands in the follow-up commit.
2026-06-07 21:25:01 +03:00

Red Bear OS

Red Bear OS

A microkernel operating system written in Rust, derived from Redox OS

MIT x86_64 Status


What is Red Bear OS?

Red Bear OS is a general-purpose, Unix-like operating system with a microkernel architecture, written in Rust. It is a full fork of Redox OS, frozen at release 0.1.0, with added hardware support, filesystem drivers, and a KDE Plasma desktop path.

Goals:

  • AMD & Intel parity — first-class support for both platforms on bare metal
  • KDE Plasma desktop — Wayland-based desktop environment via the KWin compositor
  • Hardware GPU acceleration — AMD GPU (amdgpu) and Intel GPU drivers via redox-drm
  • Modern subsystems — USB, WiFi, Bluetooth, ext4, GRUB, D-Bus
  • Offline-first builds — reproducible from archived, BLAKE3-verified sources

Quick Start

Prerequisites

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

Build & Run

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

# Build and run the desktop target in QEMU
./scripts/run.sh --build

# Build a live ISO for bare metal
./scripts/build-iso.sh redbear-full

# Build the text-only recovery target
./scripts/run.sh --build --config redbear-mini

Repository Hosting

The canonical Red Bear OS Git server is Gitea at https://gitea.redbearos.org/vasilito/RedBear-OS.git. GitHub is not a Red Bear OS source of truth and must not be used for pushes, issues, releases, or project coordination.

Public Scripts

Script Purpose
scripts/run.sh Build and run in QEMU (-b to build, -c <config> for target)
scripts/build-iso.sh Build a live ISO for bare-metal boot
scripts/build-all-isos.sh Build all live ISO targets
scripts/network-boot.sh PXE network boot helper
scripts/dual-boot.sh Dual-boot installation helper

Config Targets

Target Type Description
redbear-full Desktop Wayland + KDE + GPU drivers + D-Bus services
redbear-mini Console Text-only recovery / install target
redbear-grub Console Text-only with GRUB boot manager

Current Status

Red Bear OS boots to a login prompt in QEMU with working wired networking, D-Bus system bus, hardware detection daemons, and filesystem support (RedoxFS, ext4, FAT).

Area Status
Boot (ACPI/x2APIC/SMP) Bare-metal proven
Userspace drivers (PCI, storage, net) Working in QEMU
D-Bus system bus + services Working (login1, PolicyKit, UDisks, UPower)
ext4 / FAT filesystems Compiles, installer-wired
POSIX gaps (relibc) 🚧 Bounded Wayland-facing support
DRM/KMS display drivers 🚧 AMD + Intel compile; HW validation pending
Wayland compositor 🚧 Bounded proof; Qt6/KF6 clients crash at init
KDE Plasma desktop 🔄 In progress (Qt6/KF6 compile; KWin/QML blocked)
WiFi / Bluetooth 📋 Planned (architected, implementation pending)

How It Works

Red Bear OS uses a userspace driver model — all drivers run as unprivileged daemons:

Kernel (microkernel)
  └── schemes: memory, irq, event, pipe, debug
        └── Driver daemons (userspace)
              ├── pcid        → PCI enumeration
              ├── e1000d      → Intel ethernet
              ├── xhcid       → USB controller
              └── vesad       → Display framebuffer

The kernel provides minimal services (memory, interrupts, IPC). Everything else — filesystems, networking, graphics, input — runs in userspace.

Documentation

Contributing

Red Bear OS uses a full fork model. Upstream Redox sources are frozen and archived. All custom work lives in local/:

local/
├── sources/     # Red Bear source forks (git repos, directly editable)
├── recipes/     # Custom packages (drivers, GPU, system)
├── docs/        # Integration and planning docs
└── scripts/     # Build, test, and release tooling

We welcome contributions made with or without AI assistance — we care about quality, not how the code was produced.

License

MIT — same as upstream Redox OS.

S
Description
RedBear Operating System, based on RedoxOS. Licenced under MIT license.
https://redbearos.org
Readme MIT 20 GiB
Languages
C 43.9%
C++ 23.5%
Makefile 7.3%
Python 3.7%
JavaScript 3.4%
Other 17.1%