Update submodule pointer to cbd40e0d (base fork master).
Per USB-IMPLEMENTATION-PLAN.md v2 P0-A1: xhcid/src/main.rs:141 formerly
hardcoded (None, InterruptMethod::Polling), bypassing the complete
get_int_method() that handles MSI-X/MSI/INTx. The IrqReactor's
run_with_irq_file path is fully wired and activates when irq_file is
Some — no other code assumed polling-only.
Oracle review confirmed correct register reads, loop continuation, and
EHB clearing already in the baseline. P0-A1 is a single-line restore.
- relibc: variadic sem_open and local fork path deps
- base: already at latest RedBear-OS submodule/base
- bootloader/kernel/libredox/userutils: pushed local path-dep fixes
- installer/redoxfs: diverged from remote submodule/*; local commits saved,
divergence to be resolved after build
- driver-manager: add syscall path dependency
- AGENTS.md: document +rb build metadata and no-patches-for-local-forks rule
- remove dead patch symlinks from recipes/core/relibc (path-source local fork)
The local bootloader fork claims to be upstream 1.0.0 + Red Bear
patches, but the patches in local/patches/bootloader/ do NOT
apply cleanly to upstream 1.0.0. The fork was originally a 0.1.0
baseline with substantial additions that pre-date the upstream-1.0.0
refactor.
Changes:
* local/fork-upstream-map.toml: set bootloader's upstream tag to
PENDING_REBASE. The verifier recognises this as a deliberate
state marker (a fork whose rebase is in progress) and refuses
the build with a clear error pointing the user to the rebase
procedure documented in the map.
* local/scripts/verify-fork-versions.sh: when a fork is marked
PENDING_REBASE in the map, the script reports a dedicated error
message instead of running the upstream content comparison (which
would always fail for a fork in this state).
The current state of the build is:
* 5 of 6 `-rb1` Cat 2 forks pass the no-fake-version-label
check (redoxfs, redox-scheme, kernel, installer, userutils).
* bootloader refuses to build until a real rebase onto a chosen
upstream tag is completed (the patches must apply cleanly with
--fuzz=0).
* installer has additional divergent content that may need a
rebase too (separate operational task).
This is the strict enforcement the user asked for. The build
cannot proceed silently with fake labels. The user must drive
the rebase work for bootloader (and installer) following the
procedure in fork-upstream-map.toml.
Red Bear OS needs a local fork of redox-scheme to enforce the -rb1
version policy end-to-end. crates.io redox-scheme 0.11.2 pins
redox_syscall = "0.9.0" exactly and libredox = "0.1.18" exactly,
which Cargo refuses to satisfy with the local -rb1 forks.
The fork is implemented as a TRACKED TREE under local/sources/redox-scheme/
on the active 0.2.5 branch (per local/AGENTS.md), not as a separate
git repository or as a separate submodule on its own branch.
The single-repo rule from local/AGENTS.md is preserved: this
directory is a regular subdirectory of the RedBear-OS repo, not a
separate repository.
Add comprehensive policy documentation in AGENTS.md covering:
- local/ fork always takes precedence over recipes/ paths
- build system must ensure local fork is at latest available version
- all Red Bear patches must be applied cleanly on top of latest version
- automatic version bump + patch reapplication via bump-fork.sh
Create local/scripts/bump-fork.sh that implements automatic version bumping:
- Detects current local version vs required version from Cargo.lock
- Fetches upstream source at required version
- Applies all Red Bear patches atomically
- Updates version field and replaces local fork contents
Fix driver-manager Cargo.toml lockfile collision:
- Remove redundant syscall dependency (transitive via pcid_interface)
- Update all driver recipes to use local/sources/syscall and libredox paths
- This eliminates the redox_syscall lockfile collision between
local/sources/syscall and recipes/core/base/syscall (same dir, different paths)
relibc: fix unsafe call for Rust 2024 edition compatibility
All three were blocking the boot scheduler in /usr phase on live-mini
because their daemons never notify readiness without hardware present.
- 00_gpiod.service: scheme -> oneshot_async
- 00_i2cd.service: scheme -> oneshot_async
- 00_pcid-spawner.service: new override, oneshot -> oneshot_async
- base: update submodule to 4a1d1f4 (scheduler counter)
Updates kernel submodule to 573b3e6 which replaces context::current()
with context::try_current() in excp_handler(), preventing the cascading
'not inside of context' panic when a page fault occurs during BSP's
start() before context::init() runs.
vasilito
vasilito