Session 14 entry covering b8c1c780d (first C-7 migration
patch + v2 script unfetch-before-fetch fix). Updated
durability caveat: 13 most recent commits cover the full
arc; commit history table gets the new b8c1c780d and
975cda686 rows; test count 120 -> 122. Removed a duplicate
975cda686 row that was added by accident in the previous
edit.
Add a single-target aggregate `make lint-build-system-all`
that runs every offline-safe lint + every test + every
smoke test in one shot. Per the user request to make the
'build system healthy?' question easy to answer.
New `make lint-build-system-all` target chains:
make test-lint-scripts (120 Python unit tests)
make test-migration-dry-run (C-7 KF6 sed migration)
make test-scratch-dry-run (improvement #10 skeleton)
All exit 0 in offline mode; <3s wall-clock total.
The existing `make lint-build-system` chain was
incomplete — it ran lint-patches, lint-kf6-deps, and
lint-cook-recipe but not lint-recipe, test-migration-dry-run,
or test-scratch-dry-run. This commit fixes that:
make lint-build-system: lint-patches lint-kf6-deps \
lint-cook-recipe lint-recipe
The two aggregates serve different purposes:
- `lint-build-system` is the historical aggregate
including lint-patches. lint-patches returns 2 in
--no-fetch mode (all skipped) so the Gitea workflow
wraps it in a case statement. The original use case was
'is the project build-system clean?', which is
network-dependent.
- `lint-build-system-all` is the new offline-only
aggregate. It does NOT include lint-patches, so it
always exits 0 on a healthy tree. The new Gitea job
depends on unit-tests + lint-recipe + migration-dry-run
+ scratch-dry-run (so it can run after the four per-step
lints have already validated the individual layers).
Wired into:
Makefile:
- `make lint-build-system-all` + `make lint-build-system`
both now include lint-recipe.
- Both targets added to .PHONY.
Gitea Actions:
- New job `lint-build-system-all` (job 7 of 11, depends
on the four per-step lint jobs).
- Renumbered the docs stage to 1i.
BUILD-SYSTEM-IMPROVEMENTS.md:
- Make targets table: added scratch-rebuild, lint-build-system-all.
BUILD-SYSTEM-V6-HARDENING-POSTMORTEM.md:
- Durability caveat: 11 most recent commits -> 12 most
recent (added e1c2e7958); updated flow description to
include 'postmortem rebalance in e1c2e7958'.
Verified:
`make lint-build-system-all` passes in <3s.
11-job Gitea Actions pipeline YAML validates.
120/120 Python tests pass.
Two follow-up items from the #10 PARTIAL commit (0f8ad8a50):
1. Added `make scratch-rebuild` target to the Makefile. The
v2 of scratch-rebuild.sh supports running without --dry-run
but there was no actual make wrapper for it. The new
target runs the script in non-dry-run mode (deletes
target/<arch>/{build,sysroot,stage.tmp}/ per recipe in
the closure and re-cooks in dep order). JOBS=N (default 4)
controls the parallel rebuild workers. Verified end-to-end:
the rebuild correctly deletes the 6-recipe closure's
build dirs and starts a parallel cook. m4 succeeds; bison
fails (missing host toolchain dep) — the failure is
correctly captured to the log without aborting the script.
2. Updated BUILD-SYSTEM-V6-HARDENING-POSTMORTEM.md to reflect
the 13-session / 9.5-DONE / 120-Python-test state:
- Added Session 13 entry covering #10 foundation + tests
+ the Python regex gotcha discovered during testing
(`^[[:space:]]*` vs `^[\s]*`)
- Updated test count: 99 -> 120 Python (now 7 test files
in local/scripts/tests/, was 4 at session 1)
- Updated scope line (12-session -> 13-session)
- Updated durability caveat (10 most recent commits -> 11
most recent commits; added `0f8ad8a50` and `9e5794ea7`)
- Updated 'What remains uncommitted' table
- Updated commit history table with rows for
`827895d32`, `9e5794ea7`, `0f8ad8a50`
- Added `test_scratch_rebuild.py` row to test coverage
table
BUILD-SYSTEM-IMPROVEMENTS.md was already updated in the
#10 commit (PARTIAL status, make target table, Implemented
#10 entry). This commit re-confirms those updates after
the postmortem rebalance.
Total state:
- 9.5/10 build-system improvements DONE (1 PARTIAL on #10)
- 120/120 Python tests + 27/27 Rust tests pass
- 10-job Gitea Actions pipeline
The build-system hardening arc is now as complete as a
single-session work scope allows. Further work requires
either the multi-day #10 full L-sized verification, the
multi-week #7A QML gate, or one of the larger blocked cooks
(sddm, KF6 dep chain).
L-sized improvement #10 (cookbook scratch-rebuild) is now
PARTIALLY shipped: the M-sized foundation is a runnable
script that does the right thing in the common case.
Verification against real cascades + integration with
rebuild-cascade.sh remains for a separate session.
local/scripts/scratch-rebuild.sh (190 lines, +x):
Step 1: discover autotools-using recipes by content regex
(aclocal|autoreconf|libtoolize|automake|autoconf|gettextize|./configure)
PLUS the AUTOTOOLS_CORE list (m4, autoconf, automake,
libtool, bison, flex, gettext) which are always-included
because they are autotools infrastructure even if they
don't directly invoke aclocal.
Step 2: compute transitive closure via BFS over the recipe
TOML dep graph, including both [build].dependencies and
[build].dev_dependencies. Found 6 autotools users in the
live tree: bison, diffutils, flex, grub, libtool, m4.
Step 3: for each recipe in the closure, delete
target/<arch>/{build,sysroot,stage.tmp}/ — PRESERVE source/
so we don't re-fetch the upstream tar.
Step 4: re-cook in dep order with --jobs=N (default 4) so
the rebuild itself runs in parallel via the dep-aware
scheduler (#1).
Cook errors during Step 4 do NOT abort the script with
exit 1 — a failed cook may indicate a missing upstream dep
(legitimate on a fresh checkout) rather than a real bug.
The user inspects the log and re-runs after addressing the
dep. This is documented in the header + Step 4 comment.
Supports --dry-run, --jobs=N, --help. Env overrides for
RECIPES_DIR + LOG_DIR (mirroring the migration script's
test escape hatch pattern, used by the test suite below).
21 unit tests in local/scripts/tests/test_scratch_rebuild.py:
TestAutotoolsCoreList (3) — m4, libtool, bison/flex
in AUTOTOOLS_CORE
TestAutotoolsContentRegex (8) — catches each canonical
autotools command; does
NOT match cmake/make/meson
TestRecipeDepParsing (4) — parses dependencies and
dev_dependencies; both;
neither
TestScriptHelp (1) — --help describes the
script
TestScriptStructure (5) — executable bit; uses
./target/release/repo;
PRESERVES source/; uses
--jobs=N; dry-run safe
Test count: 99 -> 120 (all in <1s).
The test file also surfaces a real Python regex gotcha:
`^[[:space:]]*` (POSIX char class with quantifier) silently
fails to match the empty string under Python's regex
engine, while `^[\s]*` (shorthand) works correctly. The
test regex uses the shorthand to avoid this.
Wired into:
make test-scratch-dry-run -> scratch-rebuild.sh --dry-run
Gitea Actions job scratch-dry-run (job 6 of 10, every PR)
With this commit, 9 of 10 build-system improvements in
BUILD-SYSTEM-IMPROVEMENTS.md are DONE (1 PARTIAL on #10);
the remaining 1 is #7A (QML gate, Qt6 engine fix, not a
cookbook improvement).
Verified: `./local/scripts/scratch-rebuild.sh --dry-run`
correctly discovers 6 autotools users and computes the
6-recipe closure. `make test-lint-scripts` still passes
120/120 tests in <1s. Gitea workflow YAML validates with
10 jobs total (was 9).
Commit 827895d32 added the C-7 KF6 sed migration script v2
and 13 unit tests, but didn't wire the new make target or
Gitea Actions job. This commit adds both so the migration
smoke test runs on every PR.
Makefile:
- New `make test-migration-dry-run` target. Runs
`migrate-kf6-seds-to-patches.sh --dry-run --limit=1`.
Discovers candidates, prints the per-recipe plan, exits 0
on success. Does NOT do any fetches, cooks, or patch
writes. <5s wall-clock. Added to `.PHONY:`.
- Picked up automatically by the existing
`make test-lint-scripts` discovery path (the new test
file is in local/scripts/tests/, so it's already covered
by the existing target — no change there).
Gitea Actions (`.gitea/workflows/build-system.yml`):
- New job `migration-dry-run` (job 5 of 9, depends on
`unit-tests`, runs on every PR + branch push + schedule).
Triggers `make test-migration-dry-run` and treats
exit 0 as success.
- Renumbered subsequent stage headers to 1f (was 1e).
- Updated unit-tests job description: '55 cases' -> '99
cases' (reflects the new 13 migration tests).
Docs:
- BUILD-SYSTEM-IMPROVEMENTS.md: added the new make
target to the Make targets table.
- BUILD-SYSTEM-V6-HARDENING-POSTMORTEM.md: Session 12
entry covers the v2 migration script + 13 tests + CI
integration. Updated test count (86 -> 99 Python),
scope line (11-session -> 12-session), C-7 finding
(now 'migration script v2 ... now runnable; per-recipe
execution + recipe rewrite still manual'), and
durability caveat (10 most recent commits now cover
the migration work + this postmortem itself).
- Added the test_migrate_kf6_seds.py row to the test
coverage table.
Verified:
- `make test-migration-dry-run` discovers 1 candidate
and exits 0 in <1s.
- `make test-lint-scripts` still passes 99/99 tests
in <1s.
- Gitea workflow YAML validates: 9 jobs total
(was 8).
The 3 new commits since the postmortem was first written
(5325360b4 status reporter, fbc32a6d8 parallel cook pool)
advance the v6.0 hardening arc from 7/10 DONE to 9/10 DONE.
This update captures Sessions 10 and 11 with the actual
deliverables, commit hashes, and end-to-end verification
notes.
Updates:
- Session 10 row: ae749ffb2 (22 build-system files) +
5325360b4 (status reporter, src/cook/status.rs +
src/bin/repo.rs wiring).
- Session 11 row: fbc32a6d8 (src/cook/scheduler.rs +
src/cook.rs registration + --jobs=N flag in
src/bin/repo.rs + 7 dep_levels unit tests).
- Final state: 9 DONE (was 7), 1 OPEN (#10 scratch-rebuild).
The OPEN row is now explicitly flagged as
Qt6-engine-fix vs cookbook-improvement and noted as
appropriate for a separate session.
- Test coverage: 86/86 Python + 27/27 Rust (was 55/55 +
20 Rust). Added 6 status + 7 scheduler tests.
- Durability caveat: now notes 8 most recent commits cover
the v6.0 deliverables; remaining in git status is this
postmortem itself + the user's WIP.
- Replaced the 'What to commit (suggested)' block + the
'Files in v6.0 hardening arc (clean tree, ready to
commit)' table with the actual commit history table
(3 commits, durable in git) and a 'What remains
uncommitted' table listing only the postmortem itself +
user WIP paths the next commit will need to be careful
about.
When the user runs `repo cook A B C D`, the cookbook cooks the
transitive closure of those recipes strictly serially — even
recipes in the same dep level that have no inter-deps. On a
15-recipe KF6 batch this costs ~2 hours wall-clock when the
same batch could cook in ~45 minutes if level-0 recipes
ran in parallel.
Add `repo cook --jobs=N` to enable dep-aware level
parallelism. Default is 1 (serial — current behavior
preserved). The flag is only honored when the ratatui TUI
is off (CI=1 mode); the TUI has its own per-recipe
scheduling and is unchanged.
src/cook/scheduler.rs implements `dep_levels()`: walks the
already-dep-first `Vec<CookRecipe>` from
`get_build_deps_recursive`, computes
`levels[i] = 1 + max(level of any direct dep in this vec)`
or 0 if no deps in the vec. Grouping by level gives the
topological wavefront — recipes in level 0 are independent
and can cook concurrently; level 1 depends only on level 0;
etc.
src/bin/repo.rs: when jobs > 1 and !tui, replace the serial
`for recipe in recipes` loop with a level-driven parallel
loop using `std::thread::scope` (Rust 1.78+). For each
level: spawn up to `jobs` worker threads, each calling
`repo_inner()` with its own &mut StatusReporter, then
drain completed handles before advancing to the next level.
The drain-after-spawn pattern keeps live-worker count <= jobs
even for a 1000-recipe batch.
Cloning the references in scope is required for the
thread::scope closures (references are Copy, so a single
`let recipes_ref = &recipes;` works across all spawns). The
`cook_one` helper function takes all needed data as
parameters (no captures) so it can be called from both
serial and parallel paths. Test count: 20 -> 27 (7 new
dep_levels() unit tests covering empty / single / linear /
independent / diamond / dev_dependencies / unknown-dep).
Verified end-to-end with a 5-recipe batch:
$ CI=1 ./target/release/repo cook --jobs=4 \
redbear-statusnotifierwatcher redbear-traceroute \
redbear-udisks
[01/05] redbear-statusnotifierwatcher: starting
[02/05] redbear-traceroute: starting
[03/05] expat: starting
[01/05] redbear-statusnotifierwatcher: fetched (0s)
[02/05] redbear-traceroute: fetched (0s)
[02/05] redbear-traceroute: built (2s)
[02/05] redbear-traceroute: done (total 2s)
[03/05] expat: fetched (5s)
[01/05] redbear-statusnotifierwatcher: built (17s)
[01/05] redbear-statusnotifierwatcher: done (total 17s)
[04/05] dbus: starting <- level 1
[04/05] dbus: cached
[05/05] redbear-udisks: starting <- level 2
...
Level 0 ran 3 recipes in parallel; level 1 (dbus) and level 2
(redbear-udisks) advanced after level 0 finished. On a clean
rebuild (rm -rf target/ first), parallel was modestly faster
than serial on a 3-recipe batch (45s vs 48s) — the speedup is
bounded by the longest single build (17s for the heaviest
recipe). The 2-3x gain from the proposal is on a 15-recipe
KF6 batch where the longest build is 5-10 min, not a
3-recipe batch where it's 17s.
Caveat: the shared `build/qt-host-build` host toolchain
is not currently locked. A parallel cook that triggers two
qt-host-build recipes simultaneously could race. Mitigation
for v2: `flock` around qt-host-build invocations in
src/cook/script.rs. Not done in this commit because no
current test recipe triggers qt-host-build in the redbear-full
path, and the host-build path is host-cargo, not
cross-cargo, so the race window is narrow.
With this commit, 9 of 10 build-system improvements in
BUILD-SYSTEM-IMPROVEMENTS.md are DONE. The remaining #10
(cookbook scratch-rebuild system) is L-sized (1 week,
M risk) and a separate session.
When the cookbook runs without its ratatui TUI (e.g. `CI=1 repo cook
...` from a real terminal, SSH session, or backgrounded shell), the
only progress output is the per-recipe tail of the build script. The
user has no aggregate '5/15 done' view, no per-phase signal (fetch vs
build vs package), and no elapsed-time.
src/cook/status.rs adds a one-line StatusReporter that fills that
gap. Auto-enables when the TUI is off AND log capture is off AND
stderr is a TTY. Output format:
[05/15] kf6-kio: starting
[05/15] kf6-kio: fetched (3.2s)
[05/15] kf6-kio: built (4m 18s)
[05/15] kf6-kio: done (total 4m 23s)
Cached recipes emit `[NN/MM] recipe: cached` (no phase breakdown).
Writes to stderr via eprintln! so it never gets mixed with the
captured build-script log. The ratatui TUI in run_tui_cook() is
unchanged — this is the parallel status path for non-interactive
cooks.
Wiring: a &mut StatusReporter is created in main_inner's cook loop,
threaded through repo_inner() and the per-phase closures in
src/bin/repo.rs. Two phase emissions per recipe: `fetched` (after
handle_fetch) and `built` (after handle_cook, ONLY when the build
is not cached — cached cooks skip the 'built' emission to avoid
confusion). 6 unit tests cover format_elapsed boundaries, the
disabled no-op path, and phase tracking. Rust test count:
14 -> 20 (all pass in 3.2s).
Verified end-to-end with a real multi-recipe cook:
CI=1 ./target/release/repo cook redbear-statusnotifierwatcher \
redbear-traceroute \
redbear-udisks
[01/05] redbear-statusnotifierwatcher: starting
[01/05] redbear-statusnotifierwatcher: fetched (0s)
[01/05] redbear-statusnotifierwatcher: cached
[02/05] redbear-traceroute: starting
[02/05] redbear-traceroute: fetched (0s)
[02/05] redbear-traceroute: built (2s)
[02/05] redbear-traceroute: done (total 2s)
[03/05] expat: starting
...
Per build-system improvement #4. With this commit, 8 of 10
improvements in BUILD-SYSTEM-IMPROVEMENTS.md are DONE. Remaining:
#1 (parallel cook pool), #7A (QML gate), #10 (scratch-rebuild).
The v6.0 build-system hardening arc lands 5 of the 10 improvements
proposed in local/docs/BUILD-SYSTEM-IMPROVEMENTS.md. All scripts
have unit tests (62 -> 86, all pass in <1s) and the new 'lint-recipe'
Gitea Actions job runs on every PR.
Per-recipe audit & lint scripts (catch R1/R2 violations BEFORE cook):
* audit-patch-idempotency.py — verifies external patches in
local/patches/ still apply against the upstream pinned rev.
Caught 1 real bug on first run: libdrm/02-redox-dispatch.patch
hunk at xf86drm.c:321 no longer matches libdrm-2.4.125.
* audit-kf6-deps.py — fetches upstream, scans for
find_package(KF6Xxx REQUIRED), compares to recipe deps. Catches
missing + dead dependencies in every kf6-* and qt* recipe.
* classify-cook-failure.py — 17-rule cook-failure classifier.
10-30s diagnosis vs 5-10min manual. exit code is intentionally
inverted (0=novel failure, 1=known fix) for CI signal.
* lint-recipe.py — 7-rule recipe lint: R1-NO-PATCH-FILE,
R1-PATH-SOURCE, R2-INLINE-SED, R2-PATCHES-DIR-UNUSED,
NO-LEGACY-MAKE, R1-LEGACY-APPLY-PATCHES, DEP-NOT-FOUND.
1.1s for 171 recipes (down from 60s+ in v1 via recipe-index
precomputation). Strict mode promotes warnings to errors.
Build-system convenience:
* repair-cook.sh — incremental-build optimizer.
Equivalent to 'repo cook <pkg>' but with a fast-path that
skips configure when CMakeCache.txt is newer than source AND
external patches haven't changed. 30-60s vs 5-10min on KF6
recipes. make repair.<pkg> / make clean-repair.<pkg> targets.
* migrate-kf6-seds-to-patches.sh — migration skeleton for
converting 56 inline 'sed -i' chains across the KF6 recipes
to durable external patches in local/patches/<name>/.
Gitea Actions (host-execution, no Docker):
* .gitea/workflows/build-system.yml — 8-job pipeline:
unit-tests, lint-offline, lint-network (nightly),
lint-recipe (NEW), lint-docs, build-mini, build-full,
smoke (QEMU boot).
* .gitea/RUNNER-SETUP.md — one-time Manjaro/Arch host setup.
Build script hardening:
* build-redbear.sh — when a low-level source (relibc,
kernel, base, bootloader, installer) is newer than its pkgar,
clean build/ and sysroot/ across all recipes too. Low-level
package changes leave autotools packages (pcre2, gettext,
libiconv, ...) with stale configure/libtool scripts referencing
the old runtime, causing 'libtool version mismatch' and
'not a valid libtool object' errors. Cleaning forces
re-configuration; stage/ and source/ are preserved so the
cookbook skips unchanged packages that don't use autotools.
* Makefile — wire lint-cook-failure,
lint-cook-failure-explain, lint-recipe, lint-recipe.%,
lint-recipe.strict, lint-recipe.%.strict, repair.%,
clean-repair.%, test-lint-scripts[-quiet]. Replace the
legacy 'validate-patches' target with a deprecation notice
pointing at validate-sources.
Documentation:
* BUILD-SYSTEM-IMPROVEMENTS.md — mark #2 and #5 DONE; full
implementation notes; updated Make-targets table.
* BUILD-SYSTEM-V6-HARDENING-POSTMORTEM.md (NEW) — 226-line durable
record of the 8-session arc: 32 findings categorized, 5 P0
audit-script bugs fixed, 6 over-broad multi-pattern rules
discovered + fixed, test coverage 86/86 in <1s, 7/10
improvements DONE.
* SCRIPT-BEHAVIOR-MATRIX.md — apply-patches.sh row marked
LEGACY/ARCHIVED; build-redbear.sh row no longer claims to
call it.
* boot-logs/README.md (NEW) — frozen-evidence policy:
'do not edit' rule for REDBEAR-FULL-BOOT-*-RESULTS.md files.
* libdrm/02-redox-dispatch.patch.README (NEW) — 8-step regen
procedure for the broken hunk.
Cleanup:
* local/cache/README.md deleted (1-line placeholder).
* legacy 'make validate-patches' target removed.
Per build-system improvement #5: lint-recipe.py's first run on
the live tree surfaced 1 broken-patch reference (redbear-sessiond),
1 dangling cookbook_apply_patches call (tc), 19 sed -i calls in
sddm (warning — cookbook_apply_patches present, drop-x11.py
migration in progress), 4 sed -i calls in qt6-wayland-smoke
(uncovers the same bug class the libwayland fix prevented).
rtcd: syscall::openat(0, '/scheme/sys/update_time_offset') used fd 0
(stdin) instead of the namespace fd, causing EACCES. Fixed by using
libredox::call::getns().
acpid: AmlPhysMemHandler captured pci_fd at construction as
Arc<Option<Fd>>, so after set_pci_fd() stored the fd, the handler
never saw it. Changed to Arc<RwLock<Option<Fd>>> shared between
AcpiContext and the handler.
Base fork commits: 770694d0 (rtcd), 84573feb (acpid)
The cub AUR→RBPKGBUILD→recipe.toml conversion pipeline (located at
local/recipes/system/cub/source/) was assessed end-to-end against
12 representative real-world PKGBUILDs:
- libevdev (simple meson)
- fd-find (cargo)
- libpciaccess 0.18.1 (meson)
- fmt (cmake)
- wlroots-git (git source, complex deps)
- libpciaccess 0.19 (extra/-style, meson + ninja)
- ffmpeg (configure + options)
- mesa 24.3 (git+url + multi-source + pkgver())
- gzip (configure + git source + check)
- zlib (simple C, configure)
- openssl (pkgbase split package)
- glib2 (complex deps, real-world)
The assessment found 8 critical bugs that would prevent cub from
producing working Red Bear recipes for any real Arch package. 7 of
the 8 bugs were fixed in the previous commit (7c5b1f36e); the 8th
(custom-template recipes lack DYNAMIC_INIT and cookbook_apply_patches
boilerplate) is deferred as a cookbook-integration concern.
This commit adds two artifacts of the assessment:
1. local/docs/cub-assessment-and-improvement-plan.md (508 lines,
~28KB): the complete assessment document. Sections:
- Executive summary (architecture decision + 8-bug verdict)
- What cub does well (10+ working cases)
- The 8 bugs (location, severity, root cause, fix)
- Test methodology
- Test cases by category (A: conversion success, B: dep mapping,
C: source URL, D: build template, E: edge cases, F: validation)
- Forward improvement plan (16 items in 4 tiers)
- Appendix A: cub architecture map (CLI + 17 modules)
- Appendix B: RBPKGBUILD format spec
- Appendix C: Generated recipe format vs. real Red Bear recipe
2. local/recipes/system/cub/source/cub-assessment/:
a 12-PKGBUILD integration test harness. A standalone binary that
exercises the conversion pipeline on each PKGBUILD and reports
status, warnings, action_items, recipe validity (TOML), and the
first 30 lines of the generated recipe. Used to verify the bug
fixes in 7c5b1f36e — all 12 cases convert successfully
post-fix, including the previously-erroring mesa 24.3 (which
now produces a valid recipe with a multi-source warning).
The test harness lives next to the cub source (cub-assessment/) and
has its own Cargo.toml with [workspace] empty so it doesn't join the
cub workspace. Build/run with:
cd local/recipes/system/cub/source
cargo run --manifest-path cub-assessment/Cargo.toml
The harness is intended for use by future cub maintainers to catch
regressions. It's not wired into CI yet — that would be a separate
task.
This is the final cleanup batch for the Rule 2 big-project migration
work (pipewire, wireplumber, mesa, libdrm all migrated to upstream git
+ external patches in local/patches/<component>/).
Changes:
* local/recipes/libs/libdrm/recipe.toml: upgrade from
template = 'meson' + mesonflags to template = 'custom' +
DYNAMIC_INIT + cookbook_apply_patches + cookbook_meson. This
matches the structural pattern used by the other 3 Rule 2
migration recipes (mesa, pipewire, wireplumber) and gives libdrm
the same flexible shell-script build context for future
cross-compilation tweaks. Adds build dependencies expat,
libpciaccess, meson, ninja-build, pkgconf (the meson template
had these implicit; the custom template requires them explicit).
Patch application still goes through cookbook_apply_patches
(4 dots from local/recipes/libs/libdrm/ to project root).
* local/recipes/AGENTS.md: catalog update reflecting the libdrm
template change (now 'custom' instead of 'meson') and adding
catalog entries for 4 recipes that were created during this
migration round but were missing from the catalog: libxkbcommon,
pam-redbear, pipewire, wireplumber.
* sources/redbear-0.1.0/manifest.json: add a new manifest entry
for 'libs/libdrm' (the historical 0.1.0 archive entry for libdrm,
which uses the patched tarball). This mirrors the existing
'lib/libdrm' entry and gives 'repo restore' a consistent way to
recover the libdrm source from the 0.1.0 release archive.
* Doc updates: AGENTS.md, README.md, local/AGENTS.md,
local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md, local/docs/GPU-MESA-
KDE-CHAIN-ASSESSMENT.md, local/recipes/AGENTS.md: bring the
docs in line with the Rule 2 policy and the 4-migration set
(pipewire, wireplumber, mesa, libdrm). Most are catalog or
cross-reference updates.
* local/docs/STUBS-FIX-PROGRESS.md: heavily trimmed (-303 net).
The old document was tracking 346+ stub fixes from earlier
sessions; most of those are now closed and the document has
been condensed to the current state.
* local/docs/SOURCE-OWNERSHIP-MODEL.md: deleted (-89 lines).
This old doc described a 'source ownership' concept that has
been superseded by the amended AGENTS.md Rule 2 (NO OVERLAY-
STYLE PATCHES — SCOPED POLICY) section, which is the canonical
source-ownership model going forward.
Captures the QEMU boot of the redbear-full target after the
VIRTIO_BLK_F_RO read-only fix landed in local/sources/base (commit
cffacf591 virtio-blkd: handle read-only drives gracefully). The
boot now proceeds past the previously-fatal virtio-blkd
assert_eq!(*status, 0) abort and continues through the rest of
the desktop init path, validating the fix end-to-end on the
desktop target.
The pre-fix pair is committed in the previous commit; keeping
pre/post pairs adjacent in main-repo history makes the regression
test reproducible from git alone without having to look up
when each log was captured.
Captured log: 16 893 bytes, 204 lines, same scope as the
pre-fix capture (q35 + OVMF, KVM, virtio-blk readonly ISO).
Marked-up analysis: REDBEAR-FULL-BOOT-POST-VIRTIO-BLKD-FIX-RESULTS.md
documents which init stages now reach the login prompt, which
drivers register, and what the next blocking stage is.
Captures the 300s extended QEMU boot of the redbear-full target
that exposed the virtio-blkd read-only assert. Boot progressed
through:
* PCI enumeration, pcid-spawner bring-up
* nvmed multi-queue registration
* virtio-blkd bring-up (READONLY boot ISO attached)
* ahcid probe
then panicked inside virtio-blkd during a write to the boot
drive. The ISO is attached with readonly=on (per the launcher
contract to protect the build artifact), and the driver received
VIRTIO_BLK_S_IOERR (status = 1) on what it expected to be a
writable block device; the assert_eq!(*status, 0) on line 70 of
drivers/storage/virtio-blkd/src/scheme.rs aborted the daemon.
The kernel caught the user-space invalid-opcode fault from the
aborted daemon and reported UNHANDLED EXCEPTION, CPU #0, PID 19
on the virtio-blkd scheme. Captured log is 16 893 bytes / 204
lines; the marked-up analysis (REDBEAR-FULL-BOOT-EXTENDED-RESULTS.md)
identifies the root cause and the missing VIRTIO_BLK_F_RO feature
negotiation that the follow-up commit in local/sources/base adds.
These two files are the only stable record of the pre-fix
behaviour; without them the regression test for the read-only
fix has no baseline. Both files are markdown + plain serial
console capture (no binary artifacts) and are safe to commit.
The post-fix pair (REDBEAR-FULL-BOOT-POST-VIRTIO-BLKD-FIX-RESULTS.md
+ redbear-full-boot-post-virtio-blkd-fix-20260609-181340.log)
are intentionally split into a separate commit so the pre- and
post-fix captures stay paired to their corresponding source
changes.
The previous commit 13d0543c2 introduced Phase 2.1 (Mesa EGL
Wayland migration) and was reverted in a88b43b71. This re-applies
the change directly to the mainline recipe.
Per the NO OVERLAY-STYLE PATCHES policy in AGENTS.md:
- Red Bear is a FULL FORK. recipes/ is the source of truth.
- The local/recipes/libs/mesa/ fork approach was overlay-style
and is being removed.
- Direct edits to the mainline recipe are the correct pattern.
Changes to recipes/libs/mesa/recipe.toml:
- Remove 'liborbital' from dependencies
- Add 'libwayland' and 'wayland-protocols' to dependencies
- Replace '-lorbital' link flag with:
-lwayland-client -lwayland-server -lwayland-egl -lwayland-drm
- Change '-Dplatforms=redox' to '-Dplatforms=wayland'
The mesa source's platform_redox.c (which includes <orbital.h>)
is automatically excluded from the build by meson when
Dplatforms doesn't include 'redox'. The standard Linux wayland
EGL platform (drivers/dri2/platform_wayland.c) is enabled.
Side changes:
- Remove local/recipes/libs/mesa/ (the overlay fork)
- Update local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md to reflect
Phase 2.1 status
The recipe still points at the upstream redox mesa git source
(per AGENTS.md: 'Upstream gitlab URLs are temporary ... but
unmodified upstream packages with pinned revisions' is allowed).
To complete the full-fork model, a future step is to fork the
mesa source to local/sources/mesa/ and switch the recipe to use
path = '...'.
Add the QEMU boot test results captured on 2026-06-09 from
test-redbear-full-qemu.sh. Two terminal captures (75 s and a longer
~2-min run) accompany the analysis document. The captures and the
analysis document the boot chain for the redbear-full target on
QEMU virtio-gpu, including the relationship to the redbear-mini
reference log.
Per the NO OVERLAY-STYLE PATCHES policy in AGENTS.md, edit the
mainline recipe directly rather than creating a local/recipes/
fork. This is the canonical Red Bear recipe.
Changes to recipes/libs/mesa/recipe.toml:
- Remove 'liborbital' from dependencies
- Add 'wayland' and 'wayland-protocols' to dependencies
- Replace '-lorbital' link flag with:
-lwayland-client -lwayland-server -lwayland-egl -lwayland-drm
- Change '-Dplatforms=redox' to '-Dplatforms=wayland'
The mesa source's platform_redox.c (which includes <orbital.h>)
is automatically excluded from the build by meson when
Dplatforms doesn't include 'redox'. The standard Linux wayland
EGL platform (drivers/dri2/platform_wayland.c) is enabled.
Followed-up:
- Remove local/recipes/libs/mesa/ fork (no longer needed; the
mainline recipe is now the Red Bear canonical version)
- Update local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md to mark
Phase 2.1 done (was 'skeleton recipe forked')
This is the correct, full-fork way to change a recipe. No overlay
layer, no apply-patches.sh symlink, no local fork. Just a direct
edit to the mainline recipe, which is now Red Bear's because
Red Bear is a full fork of Redox.
v6.0 collapses the v5.0 dual-path input design (which was never
built) into a single-producer evdev pipe:
drivers → /scheme/input/evdev (inputd ring buffer)
→ evdevd consumer
→ /dev/input/eventN
→ libinput
Phase 1.1b (inputd scheme daemon) is now real. All five input
drivers + virtio-inputd already use EvdevProducerHandle. The
init system wires evdevd in. Plan status for Phase 1: 8 of 9
steps code-complete; only Step 1.9 (udev-shim eventN mapping
verification) and runtime gate (QEMU boot test) remain.
Also records the small fixes this session: Gap 3 (renderD128
openat path), Gap 5 (host->guest resize events, pre-existing),
Gap 8 (atomic_check connector validation), Phase 3.5 (page
flip keeps DRM fd open), the redox-drm dangling symlink, and
the build-redbear.sh aggressive cache-nuke fix.
Gap 5: virtio IRQ handler at virtio/mod.rs:366-403 already reads
VIRTIO_GPU_EVENT_DISPLAY and calls refresh_connectors. Scheme layer
queues the hotplug event so userspace libdrm clients get notified.
Gap 8: atomic_check now validates connectors via the
available_connectors parameter — fixed in commit 32993a9ee.
- STUBS-AUDIT-AND-REWRITE-PLAN.md: master plan, 20 drivers audited
- USB-STUBS-AUDIT.md: USB stack focus, xhcid/usbhubd/usbctl/usbhidd/usbscsid/ucsid
- HID-STUBS-AUDIT.md: HID focus, usbhidd/i2c-hidd/intel-thc-hidd/ps2d/inputd/evdevd
- LOWLEVEL-STUBS-AUDIT.md: ACPI/PCI/IRQ/IOMMU/boot/init, 50+ row coverage
- BOOT-AND-HW-ENABLEMENT-ASSESSMENT.md: kernel to display chain, NO VESA policy
- DESKTOP-SERVICES-ASSESSMENT.md: D-Bus, session, audio, network
- CONFIG-AND-INIT-ASSESSMENT.md: configs, init.d, recipes, layering
- GPU-MESA-KDE-CHAIN-ASSESSMENT.md: Mesa to Plasma build chain
These documents track the v6.0 stub-fix campaign and the comprehensive
Phase 1-5 implementation work. All cited paths and line numbers are
real. Documents are durable in local/docs/ which survives make distclean.
After review push-back on the dual-path (orbclient + evdev) input
architecture, the v6.0 plan is simplified to a single evdev producer
model. The user committed: 'we do not use Orbital and do not plan to
use it. we aim for wayland/kde.'
The dual-path was rejected for:
- Doubling every driver's event-write code
- Doubling per-event syscall cost
- Out-of-order risk between the two producers
- Translating back and forth loses metadata
- No desktop consumer actually needs Orbital
The corrected architecture:
Hardware
-> single /scheme/input/evdev producer (Linux struct input_event)
-> evdevd (pure scheme->/dev/input/eventN adapter)
-> /dev/input/eventN
-> libinput in-process to KWin (user session)
-> libinput in-process to redbear-compositor (greeter)
-> direct evdev fd (Qt6 apps that need raw access)
inputd is deprecated for the desktop config. It stays in the tree
only as a historical daemon.
What this changes:
1. Phase 1 effort drops from 1-2 weeks to 1 week
2. Drivers change ONCE (replace ProducerHandle with
EvdevProducerHandle) instead of dual-writing
3. evdevd refactor is now cleaner: just switch its consumer from
/scheme/input/consumer (orbclient) to /scheme/input/evdev
(Linux evdev)
4. inputd/src/lib.rs gains a new EvdevProducerHandle, EvdevEvent,
keycodes module — committed in the base fork first
Plan updates:
- Section 2 (Unified Input Architecture) rewritten to 'Single-Producer
Input Architecture'
- Critical path Phase 1 row updated to reflect 1-week effort
- Executive summary text updated
- 'Two Architecture Decisions Resolved' updated to reflect
Orbital-out decision
This is a full v6.0 rewrite of the desktop plan, produced after:
1. Booting CachyOS desktop ISO (cachyos-desktop-260426.iso, 2.9GB) in QEMU
11.0.0 to establish the reference baseline.
2. Six parallel research agents that audited the full Red Bear stack
against the CachyOS reference and Linux 7.1 kernel source.
3. Resolution of two architectural questions that v5.x punted on.
Two non-negotiable architecture decisions (v6.0):
A. UNIFIED INPUT ARCHITECTURE: every input driver writes to BOTH
/scheme/input/orbclient (for Orbital) and /scheme/input/evdev (for
KWin + libinput). No more inputd <-> evdevd bridge that loses
metadata (timestamps, axis ranges, vendor IDs, SYN_REPORT).
Matches CachyOS/Linux: one kernel-evdev path, all consumers
read from it.
B. KWIN IS THE PRIMARY COMPOSITOR: redbear-compositor (788-line
Rust) is too small to reach production parity with KWin in any
realistic timeframe. KWin is used for the user session;
redbear-compositor hosts only the greeter (minimal xdg-shell +
wl_keyboard events are still needed for the greeter to function).
Critical path rework (v6.0):
- Phase 0: QML JIT gate (4-6 weeks) — moves to pre-flight because
it blocks 12 KF6 packages and KWin. Without QML, no Plasma.
- Phase 1: Unified input (1-2 weeks) — resolves the inputd/evdevd
proliferation.
- Phase 2: DRM atomic modeset + render node + PRIME real FDs +
RESOURCE_MAP_BLOB (2-3 weeks).
- Phase 3: Mesa EGL Wayland fix (1 week).
- Phase 4: Compositor greeter — redbear-compositor adds
xdg-shell + wl_keyboard events (2-3 weeks).
- Phase 5: KWin real build (2-4 weeks).
- Phase 6: PipeWire + wireplumber + audiod bridge (6-8 weeks).
- Phase 7: Plasma shell (4-6 weeks).
- Phase 8: QEMU E2E validation (1-2 weeks).
- Phase 9: Intel ARC track (parallel) (12-20 weeks).
Coverage inventory (v6.0):
237 components audited across 14 categories.
86 real (36%), 41 partial (17%), 110 missing (46%).
Detailed gap matrix in §8.
Intel ARC support:
Added as Phase 9 parallel track — requires Mesa iris + Xe driver
cross-compile + real hardware validation.
Total: 22-32 weeks to functional software-rendered KDE Plasma
Wayland desktop on QEMU. +4-8 weeks for Mesa virgl. +12-20 weeks
for real Intel ARC hardware.
This supersedes v5.0 and v5.1 in full. The v5.x changelog sections
(§9, §9.1, §9.1.1) are retained as historical record.
Two parallel review agents cross-checked the virtio-inputd driver against
the Linux 7.1 reference (drivers/virtio/virtio_input.c, virtio_input.h)
and the proven redox-drm virtio transport. 12 issues were found across
BLOCKER, MAJOR, MINOR, and NIT severity, all fixed in this commit before
runtime testing.
BLOCKERs (would have prevented the driver from working in QEMU):
1. fill_avail() never wrote avail_idx after pushing the 64 ring
entries. The device reads avail_ring[avail_idx % size] to discover
new buffers, so without publishing avail_idx = size, the device
saw avail_idx = 0 and ignored all initial buffers. Fix: explicit
'fence(Release); write_avail_idx(self.size)' with a spec citation.
2. drain() recycled IDs derived from 'last_used_idx - drained_count',
which is wrong when the used ring wraps and a single drain cycle
spans more than one full ring revolution. Fix: collect the actual
drained 'id' values in a stack '[u16; 64]' array during the drain
loop, then push those exact ids back to the avail ring. The
doc-comment explains why the derivation is unsafe.
3. config_read_string() and config_read_bitmap() used
'self.device_cfg.size()' (the MMIO region size = 40) instead of
the device-reported config size from offset 2. Fix: use
'config_read_size()' to read the actual size field.
4. config/redbear-full.toml: device_id_range was a TOML string
('0x1042..=0x107F') but serde's Range<u16> deserializes from a
sequence, not a string. pcid-spawner would have silently failed
to load the fragment. Fix: use serde array form
'device_id_range = [0x1042, 0x107F]'.
MAJORs (silent failure modes or runtime bugs):
5. activate_queue() had no fence between address writes and
'queue_enable = 1'. A CPU write buffer may reorder writes to
distinct MMIO addresses. Fix: explicit 'fence(SeqCst)' with
a comment citing virtio spec 2.8 and Linux's virtio_wmb.
6. No 'reset_device()' on error path after partial init. The device
would be left in ACKNOWLEDGE|DRIVER with no driver active,
requiring a guest reboot to recover. Fix: wrap init in a closure;
any error calls 'transport.reset_device()' before propagating.
7. Drain loop never checked DEVICE_NEEDS_RESET or DEVICE_STATUS_FAILED.
If the device entered an unrecoverable state, the driver would
poll forever with stale state. Fix: 'device_in_error_state()' on
the transport; loop checks it each iteration and exits cleanly.
8. The abs_count probe used 'config_read_size() == 24', which was
always false (virtio_input_absinfo is 20 bytes, not 24). The
count was always logged as 0. Fix: '>= 20' per spec.
MINORs / NITs (hardening, no functional impact):
9. config_read_absinfo() returned AbsInfo without validating
device-reported size. Now returns Option<AbsInfo> and validates
size >= 20.
10. map_cap_region() missing bounds check: capability range may
extend past BAR end (QEMU is permissive; bare-metal is not).
Added 'cap_end > bar_size' check with spec reference.
11. Legacy device 0x1052 entry in pcid fragment caused spurious
spawn + log noise. Removed.
12. notify_queue() error silently dropped with .ok(). Now logs warn
and continues.
Plan update:
The CONSOLE-TO-KDE-DESKTOP-PLAN.md v5.1 changelog now has a new
'9.1.1 Phase 5.1 review-driven fixes' section documenting all 12
findings with file:line, severity, and fix. Future maintainers can
trace the BLOCKERs back to specific commits to understand the
critical-path safety net this review provided.
Verification: cargo check zero errors, 64 warnings (all unused
keycode constants reserved for Phase 5.2 expansion). The driver
is now ready for runtime testing in QEMU.
Add a real, QEMU-targeted virtio-input driver as a new Red Bear recipe at
local/recipes/drivers/virtio-inputd/. The driver handles virtio-input-host-pci,
virtio-input-keyboard, virtio-input-mouse, and virtio-input-tablet devices and
closes Gap #19 of the v5.0 desktop plan.
The driver:
* Walks the PCI capability list to find the modern virtio 1.0 capability
block (common_cfg, notify_cfg, isr_cfg, device_cfg) using MmioRegion
mappings via redox-driver-sys. Rejects legacy virtio-input (device 0x1052)
which lacks the modern transport.
* Negotiates VIRTIO_F_VERSION_1 only (the only required feature).
* Allocates one event virtqueue (size up to 64) backed by four DMA buffers
(desc, avail, used, event_buffers) and pre-fills the avail ring.
* Polls the used ring at 60 Hz, drains completed events, decodes each
virtio_input_event (8-byte type/code/value), and recycles drained buffers
back to the avail ring.
* Translates events to orbclient format and pushes them to inputd via
ProducerHandle (Orbital path):
- EV_KEY -> KeyEvent (with US-QWERTY character mapping)
- EV_REL -> MouseRelativeEvent (REL_X/REL_Y) or ScrollEvent (REL_WHEEL)
- EV_SYN -> dropped (inputd multiplexes)
- Other -> dropped (Phase 5.2 will add evdevd path)
Probe-time checks:
* Vendor 0x1AF4, device_id >= 0x1042, revision >= 1
* Caps include a device_cfg block with virtio type == 18 (virtio_input)
Configuration: a pcid-spawner fragment is added to config/redbear-full.toml
under /etc/pcid.d/virtio-inputd.toml matching class=0x09 vendor=0x1AF4 with
device_id_range 0x1042..=0x107F (and a separate 0x1052 entry that the driver
intentionally rejects).
Verification: cargo check produces 0 errors and 65 warnings, all of which are
unused input-event-codes.h constants reserved for the Phase 5.2 expansion.
Linking the binary requires the Redox cross-toolchain (relibc provides
redox_sys_call_v0); this is provided by the build system, not the host
toolchain.
Plan: this is Phase 5.1 of CONSOLE-TO-KDE-DESKTOP-PLAN.md v5.0. The plan is
updated to v5.1 with: (a) a 'What Changed Since v5.0' section, (b) Gap #19
marked DONE, (c) Phase 5 row marked DONE with sub-task status, (d) Gate E
updated, (e) Input pipeline section updated to reflect the (c) path is now
implemented. Phase 5.2 (evdevd producer path + virtio-snd) is documented as
the next planned work but not yet implemented.
Major revision: replaces v4.1 with a code-grounded audit where every claim
is verified by direct source inspection. Corrects several false claims
in v4.1 and adds an honest gap matrix grounded in a live CachyOS
desktop ISO booted in QEMU 11.0 as the functional reference.
Corrections to v4.1:
- audiod EXISTS at local/sources/base/audiod/ (real implementation,
277 lines, mixer with volume control and HANDLE_BUFFER_SIZE=4096)
- redbear-input-headers EXISTS at local/recipes/drivers/redbear-input-headers/
(recipe.toml + source/include/linux/linux/ with input.h, uinput.h)
- inputd is a real producer/consumer multiplexer, not a stub
- synthetic_edid() is not a stub — generates valid 1920x1080@60Hz EDID
with correct checksum
- The Mesa LDFLAGS -lorbital link is the real EGL path issue, not
'EGL works'
New v5.0 findings (not in v4.1):
- ATOMIC ioctl in redox-drm passes empty connectors to set_crtc
(showstopper, scheme.rs:1733)
- No render node (renderD128) — Wayland compositors need this
- PRIME export uses in-memory token, not real DMA-BUF FD — blocks Mesa
- No VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB handler
- No host→guest resize notification processing in IRQ handler
- libdrm missing DRM lease ioctls
- redbear-compositor missing xdg-shell, zwp_linux_dmabuf, wp_presentation,
zwp_linux_explicit_synchronization (showstoppers for modern Wayland)
- redbear-compositor page flip reopens DRM fd every call
- usbhidd/ps2d send to inputd (Orbital path) not to evdevd
- evdevd not in init system of redbear-full
- No virtio-input or virtio-snd drivers (QEMU specific)
Critical path to functional QEMU Wayland desktop (12 weeks, no hardware):
Phase 1: Fix DRM atomic modeset (2-3 weeks)
Phase 2: Fix Mesa EGL Wayland (1 week)
Phase 3: Add compositor protocols xdg-shell + dmabuf + presentation (2-3 weeks)
Phase 4: Wire input pipeline to compositor (1-2 weeks)
Phase 5: Add virtio-input + virtio-snd drivers (1-2 weeks)
Phase 6: QEMU end-to-end validation vs CachyOS (1 week)
Total to software-rendered Wayland desktop on QEMU: 12 weeks.
Total to software-rendered KDE Plasma (QML gate): 18 weeks.
Total to hardware-accelerated QEMU desktop (Mesa virgl): 22 weeks.
Total to real AMD/Intel GPU: 42 weeks (requires hardware).
Cross-referenced every stub/gap claim in v1.0 against actual code and
Linux 7.1 reference (local/reference/linux-7.1/). Four parallel audits.
Key corrections to v1.0:
- kernel/src/arch/x86_shared/sleep.rs:257-276 does NOT exist; real PCI
stubs are in acpid/aml_physmem.rs:375-398 (root cause: pcid never
sends fd to acpid)
- EHCI is ALREADY implemented (1538+ lines); the stubs are OHCI and UHCI
- aml_physmem.rs:195, :274 line numbers were wrong; actual stubs at
:213-232 (map_physical_region panic) and :241-280 (read returns 0)
- MSI stub at irq.rs:231 was fixed 2026-06-08 (this audit's first task)
New gaps added (v1.1):
- Gap 11: IOMMU daemon->kernel IRQ integration missing (kernel has
set_iommu_remapping_active() but daemon never calls it)
- Gap 12: MSI multi-vector not exposed (blocks xhcid, nvmed, ixgbed,
redox-drm)
Other corrections:
- DMAR init should move to iommu daemon, not acpid
- >255 CPU ID is a panic (u8::try_from().expect()), not deferred
- hwd legacy backend stub is acceptable (graceful no-op fallback)
Added new sections:
- Section 13: Concrete Fix List (v1.1, ready to execute) with exact
file paths, line numbers, current code, target code, Linux reference
- Section 14: v1.1 Audit Methodology documenting the cross-reference
approach
All execution plan phases updated with corrected tasks, owners, and
verification gates.
Comprehensive 6-tier plan to address the 1.5h full-rebuild pathology
when making small config changes. Covers content-hash output
fingerprinting, per-crate granularity, public API surface tracking,
restat / equivalence caching, and developer-experience tools.
Synthesizes techniques from Nix, Buildroot, Yocto, GN/Ninja, Cargo,
and Bazel adapted to Red Bear OS's Rust cookbook.
Triggered by: 2-line edit to local/sources/base/Cargo.toml caused
1.5h full rebuild of redbear-mini. Root cause: cookbook tracks at
recipe granularity (one stage.pkgar for 45-member Cargo workspace)
instead of crate granularity.
Documents the two R7 audit findings and the comprehensive plan to
fully utilize the R0-R22 quirks-and-bugs subsystem.
Findings
- cb_intel_ntb_bar_fix was a no-op stub (cleared PCI_COMMAND_MEMORY
and restored it; the device never observed the transient clear).
Replaced with the real Linux quirk_intel_ntb reads at config
offsets 0xD0 and 0xD1. 3 new unit tests. 131/131 redox-driver-sys
tests pass.
- redbear-quirks install script copied only 8 of 30 TOML files,
leaving all R11-R21 data tables inert at runtime. Replaced the
explicit list with a glob.
Utilization plan
- Audit of every other cb_* callback (all justified, no other stubs).
- Full consumer-wiring matrix showing what's wired, what's not, and
the concrete step for each pending consumer.
- Initialization-path wiring from bootloader SMBIOS through kernel
to acpid/pcid/xhcid/usbhidd/evdevd/network/storage/audio/drm.
- 15-task implementation order with estimates (22-32 days sequential,
parallelizable to 2-3 devs in 4-6 weeks).
- Updated test count: 131 host-buildable redox-driver-sys + 13 acpid
dmi + 12 pcid + 7 usbhidd + 4 evdevd + 3 iwlwifi = 170 total.
After the 15 tasks land, every lookup function in redox-driver-sys
has at least one production consumer; the data tables drive real
kernel/userspace behavior; and the R0-R22 infrastructure is fully
automatically made to work on real hardware.
The previous count of 161 in the doc was an error
caused by summing test counts from different build
contexts (host-buildable redox-driver-sys + target
test-runs in consumer trees). The correct counts:
- 128 host-buildable unit tests in redox-driver-sys
(Linux source-of-truth conventions; can run on
any dev machine)
- 13 dmi unit tests in acpid (target-only)
- 12 quirks.rs unit tests in pcid (target-only)
- 7 hid + usb unit tests in usbhidd (target-only)
- 4 hid unit tests in evdevd (target-only, plus
pre-existing test errors out of scope)
- 3 wifi unit tests in redbear-iwlwifi (target-only)
- Plus consumer-side QuirkAction tests in
redox-driver-sys that may run on either target.
The headline '161' was the result of an arithmetic
slip; the corrected figure is 128 in the host-
buildable tree (redox-driver-sys) and ~167 across
all trees including the consumer targets.
kellito
vasilito