Update local subsystem planning docs

This commit is contained in:
2026-04-20 18:37:35 +01:00
parent 5683ba5dc3
commit 6343f173c9
17 changed files with 1246 additions and 1443 deletions
@@ -1,278 +1,50 @@
# Red Bear OS relibc Completeness and Enhancement Plan
# Red Bear OS relibc Assessment and Improvement Plan
## Purpose
This document assesses relibc in Red Bear OS for **strengths**, **deficiencies**, **subsystem-facing
gaps**, and **overall quality**, then defines a practical plan for improving it.
This document is the canonical Red Bear assessment of relibc quality, completeness, and robustness.
The goal is not to treat relibc as a generic libc project. The goal is to describe:
It is intentionally stricter than older relibc notes. This pass is grounded in what is visible in:
- what is already strong,
- what still depends on active local overlay state rather than upstream relibc itself,
- what is still incomplete or weak,
- what downstream subsystems still depend on relibc improvement,
- and what order of work best improves real system capability.
- 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.
This is a Red Bear-specific document. It is grounded in the current repo state rather than older,
pre-correction roadmap assumptions.
It does **not** flatten those evidence types into one generic claim of "implemented".
## Evidence Model
## Evidence model
This plan uses four evidence buckets and does **not** treat them as equivalent:
Use these labels consistently when describing relibc in this repository:
- **source-visible** — behavior visible directly in the current relibc source tree
- **patch-carried** — behavior carried in the active `local/patches/relibc/*.patch` recipe inputs rather than upstream relibc itself
- **build-visible downstream** — downstream packages now compile because the libc surface exists
- **runtime-validated** — behavior has been exercised successfully in real downstream/runtime paths
- **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 relibcs current problem is often **not** “API absent,” but the gap
between **implemented**, **patch-carried**, **build-proven**, and **runtime-trusted**.
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.
## Upstream vs Red Bear ownership
## Ownership boundary
For relibc, the ownership boundary must stay explicit:
- `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.
- `recipes/core/relibc/source/` is the live upstream-owned working tree used for actual build and
validation
- the active Red Bear-owned durable relibc compatibility carrier is the recipe-replayed
`local/patches/relibc/*.patch` set; in the current tree that active replay has narrowed to
`local/patches/relibc/redox.patch`
- older `local/patches/relibc/P3-*.patch` files are historical bring-up references unless a current
recipe still replays them
- `local/docs/...` is the durable explanation of what those changes mean and how to reapply them
For relibc, the honest maintenance target is:
That means a relibc change is not truly preserved until its ownership is explicit in the right
place:
> 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.
1. if upstream now owns the behavior, the live relibc source tree is the canonical implementation
2. if Red Bear still owns a unique delta, it must also exist in the active
`local/patches/relibc/` recipe input set so the same result can be recreated after an upstream
refresh
## Current implementation assessment
The repo standard for success is not merely “the current source tree builds.” The standard is:
### 1. Plain source and active build are materially different
> we can fetch fresh upstream relibc sources, reapply the active Red Bear relibc patch carriers, and still
> rebuild the same working result.
Any relibc work that exists only under `recipes/core/relibc/source/` should therefore be treated as
validated-but-not-yet-preserved.
Because relibc is also one of the fastest-moving upstream areas, Red Bear should apply one more
rule here:
> if a Red Bear relibc patch solves a problem that upstream has already solved, prefer the upstream
> solution and retire or reduce the local patch.
The goal is durable compatibility, not a permanent relibc fork.
## Current Repo State
> **Implementation note (current Red Bear tree):** this repo pass moved several relibc items from
> patch-carried-only or downstream-workaround status into source-visible libc behavior. The current
> tree now contains source-visible and strict Redox-target runtime-tested `signalfd`, `timerfd`, `eventfd`, `open_memstream`,
> `F_DUPFD_CLOEXEC`, `MSG_NOSIGNAL`, a bounded `waitid()` path, bounded `RLIMIT_NOFILE` /
> `RLIMIT_MEMLOCK` behavior, a bounded `eth0`-backed `net/if.h` / `ifaddrs.h` view, a source-visible
> `resolv.h` plus bounded `res_query()` / `res_search()` compatibility paths with receive/send
> timeout hardening, a first named-semaphore implementation on top of the existing shm path, and
> bounded `sys/ipc.h` / `sys/shm.h` surfaces for the `IPC_PRIVATE` / `shmget` / `shmat` /
> `shmdt` / `shmctl(IPC_RMID)` workflow.
> **Downstream validation note (current Red Bear tree):** `libwayland` now cooks successfully
> against the updated relibc, and qtbase now configures, builds, and stages with
> `FEATURE_process=ON`, `FEATURE_sharedmemory=ON`, and `FEATURE_systemsemaphore=ON` in the current
> tree. The relibc `tests/` harness also now builds focused Redox-target binaries for `eventfd`,
> `waitid`, `res_init`, `res_query`, `sem_open`, and `shmget`, and the host-target variants of those same
> focused tests now execute successfully under the relibc-built host sysroot. That does not mean
> relibc is complete, but it does mean the implementation has crossed real downstream build/stage
> gates and direct execution-level proof rather than remaining an isolated libc-only pass. The
> current host-side `res_query` proof is still bounded: it compiles, runs, and fails fast under the
> relibc sysroot instead of hanging, but it is not yet a runtime-trusted downstream DNS proof.
>
> **Additional downstream proof (current Red Bear tree):** the in-tree `openssh` recipe now cooks
> successfully against the relibc resolver surface after switching the recipe to the rebuilt relibc
> headers/libraries and removing stale Redox-specific resolver fallbacks from the OpenSSH patch.
> That is still build/stage proof rather than runtime SSH validation, but it demonstrates that real
> consumers can now compile and link `res_init`, `res_query`, and `dn_expand` from relibc.
>
> **Fresh revalidation pass (current Red Bear tree):** the focused host-side relibc proofs were
> rerun for `eventfd`, `waitid`, `res_init`, `res_query`, `sem_open`, and `shmget`; the binaries all
> built, and the executions succeeded for `eventfd`, `waitid`, `res_init`, `sem_open`, and `shmget`
> with the bounded `res_query` test still failing fast rather than hanging. The main downstream
> consumers previously used as evidence were also rerun successfully: `CI=1 ./target/release/repo cook libwayland`,
> `CI=1 ./target/release/repo cook qtbase`, and `CI=1 ./target/release/repo cook openssh` now all
> succeed in the current tree.
>
> **Additional focused coverage (current Red Bear tree):** integrated relibc tests were also added
> for `open_memstream`, SysV semaphores via `semget`/`semop`/`semctl`, `timerfd`, `signalfd`, and
> `eventfd`. On the host-side relibc sysroot, `open_memstream`, `semget`, and the bounded SysV shm
> path execute successfully. On the Redox-target runtime path, the repaired `cookbook_redoxer`
> `write-exec` flow now executes the targeted `eventfd`, `signalfd`, and `timerfd` binaries
> successfully against the staged relibc test tree, and those tests now fail hard if the APIs are
> unavailable. That moves the fd-event APIs from source-visible/build-visible status into explicit
> runtime-tested status for the bounded relibc harness.
>
> **Fresh-upstream reapply proof (current Red Bear tree):** a fresh `repo unfetch relibc` →
> `repo fetch relibc` cycle was used to reconstruct the relibc source tree from upstream-owned
> sources, the durable `local/patches/relibc/` carrier set was reapplied to that fresh tree, and the
> resulting rebuild again supported successful downstream `libwayland` and `qtbase` cooks. That is
> the current proof that Red Bears relibc work is not only buildable in-place, but also recoverable
> after a fresh upstream source refresh.
> **Current reconstructed-state proof set:** with the refreshed source tree rebuilt from the local
> relibc overlay set, the repo now has successful cookbook evidence for all three layers in order:
> `CI=1 ./target/release/repo cook relibc`, then `CI=1 ./target/release/repo cook libwayland`, then
> `CI=1 ./target/release/repo cook qtbase`. This is the strongest current proof that the relibc
> compatibility work is preserved in the right place for long-term maintenance.
>
> **Current patch-carrier note:** the bounded `ifaddrs` / `net_if` work and the bounded
> `arpa/nameser.h` / `resolv.h` compatibility work are now preserved in the tracked
> `local/patches/relibc/redox.patch` carrier instead of separate transient patch files. The durable
> relibc recipe patch chain therefore consists only of tracked local patch files plus
> `recipes/core/relibc/recipe.toml` wiring.
### Summary
relibc is one of Red Bears strongest foundational subsystems, but it is not complete.
The current repo shows a relibc that is already strong in:
- broad header/libc surface coverage
- real Redox-native platform integration
- source-visible implementations of the historical Wayland-facing P3 APIs, with patch carriers still retained as sync/upstream artifacts
- enough maturity to unlock major build-side progress in Wayland, Qt, and KDE
- a substantial generic upstream-style test tree
The current repo also shows relibc is still weak in:
- shared memory / SysV IPC completeness
- named semaphores
- process/runtime quality for some downstreams
- networking/resolver/interface completeness
- Redox-target and downstream-runtime validation depth
### Status Matrix
| Area | State | Notes |
|---|---|---|
| Core POSIX/header breadth | **strong / partial** | Large header surface exists, but many TODO headers and feature gaps remain |
| Wayland-facing P3 APIs | **implemented / runtime-tested / bounded** | `signalfd`, `timerfd`, `eventfd`, `open_memstream`, socket flags, and `F_DUPFD_CLOEXEC` now exist in the relibc source tree; strict targeted relibc runtime tests now execute on Redox, but broader consumer semantics still need careful documentation |
| Networking/libc socket surface | **usable / partial** | AF_INET/AF_UNIX paths exist, but interface/reporting/resolver behavior remains narrow |
| Qt/KDE downstream unblockers | **build-side improved / multiple gates crossed** | `QProcess`, `QSharedMemory`, and `QSystemSemaphore` now configure, build, and stage on in-tree qtbase; broader runtime validation is still needed |
| Shared memory / semaphore completeness | **partial** | `shm_open` exists through the Redox shm path, but SysV IPC/shared-memory and named semaphore completeness remain open |
| Process/runtime completeness | **partial** | Some process-facing functionality still uses stubs or downstream workarounds |
| Dedicated test surface | **present / Redox-specific coverage still thin** | relibc has a substantial `source/tests/` tree, but the Red Bear-visible Redox/P3/runtime validation story is still weaker than the generic libc test surface |
| Runtime validation against real consumers | **improved / still bounded** | relibc fd-event runtime tests now execute on Redox; broader desktop consumer semantics still need continued confirmation |
## Strong Points
### 1. relibc already exposes a broad libc/header surface
`recipes/core/relibc/source/src/header/mod.rs` shows a broad libc/header tree with networking,
threading, polling, stdio, locale, signal, socket, time, and many Unix-facing modules already
present.
That means Red Bear should treat relibc work as **quality and completeness hardening**, not as a
greenfield libc effort.
### 2. The historical P3 Wayland-facing API bridge is now source-visible
The local relibc patch carriers documented the APIs that historically blocked Wayland and downstream
consumers. In the current preserved tree, those fd-event and adjacent IPC surfaces are now present
in the active upstream relibc source itself, and the relibc-facing recipes no longer replay the old
standalone P3 carrier set for `eventfd`, `signalfd`, `timerfd`, `waitid`, SysV IPC, or their focused
test files. The active Red Bear relibc recipe replay has narrowed back to the shared
`local/patches/relibc/redox.patch` compatibility delta, while the historical P3 patch files remain
useful as prior bring-up evidence rather than current recipe inputs.
### 3. Focused fd-event proof record
The bounded fd-event runtime proof now has a small tracked record here so it does not depend only on
session history.
Preserved command shape:
- rebuild relibc from tracked carriers: `repo unfetch relibc && repo fetch relibc && repo cook relibc`
- rebuild targeted test package: `TESTBIN=sys_eventfd/eventfd CI=1 ./target/release/repo cook relibc-tests-bins`
- execute inside staged Redox target via `cookbook_redbear_redoxer write-exec`
Recorded bounded runtime markers from the current pass:
- `eventfd_runtime_finalfinal_ok`
- `signalfd_runtime_finalfinal_ok`
- `timerfd_runtime_finalfinal_ok`
- `eventfd_runtime_kernelreplay_ok`
These markers should be read as proof of the bounded relibc fd-event harness only. They do not by
themselves claim full Linux-equivalent semantics for every downstream desktop consumer.
The upstream-first policy still applies here, but the durable patch-carrier set should be trimmed
only when a fresh upstream refetch plus reapply plus downstream rebuild actually proves the upstream
coverage is sufficient. In the current Red Bear tree, `open_memstream`, `F_DUPFD_CLOEXEC`, and the
socket flag work still need to remain in the relibc overlay set because the clean reconstructed
consumer path still depends on them.
This is one of relibcs strongest current points: Red Bear already has the exact P3 compatibility
surface that older docs used to describe as absent.
The local patches still matter as provenance and sync-upstream carriers for the gaps upstream does
not yet solve, but they should be retired as soon as upstream makes them redundant.
### 3. Downstream build progress proves relibc is materially useful
The current docs consistently show that relibc has already enabled substantial downstream progress:
- `docs/02-GAP-ANALYSIS.md` now marks the P3 bridge as implemented in-tree with strict Redox-target runtime proof for the fd-event slice
- `local/docs/WAYLAND-IMPLEMENTATION-PLAN.md` says the build-side relibc/libwayland bridge is restored and that the remaining blocker is runtime validation, not basic POSIX availability
- `local/docs/QT6-PORT-STATUS.md` treats many earlier relibc blockers as moved from “missing” to “present but still needs downstream validation”
This is a major quality signal: relibc is already strong enough to unlock real build-side subsystem work.
### 4. relibc already has a substantial generic test surface
`recipes/core/relibc/source/tests/` is real and large. It already covers many libc-facing areas such
as:
- `fcntl/`
- `net/` and `netdb/`
- `pthread/`
- `stdio/`
- `sys_mman/`
- `sys_socket/`
- `sys_resource/`
- `time/`
- `unistd/`
That is a genuine strength and should be documented as one.
The remaining weakness is narrower: Red Bear still lacks a strong **Redox-target / P3 API /
downstream-runtime** validation story that is as visible and deliberate as this generic relibc test
tree.
### 5. The current relibc problem is no longer one single blocker
The downstream evidence shows that relibc now has **multiple completeness fronts**:
- Wayland-facing POSIX/event APIs
- Qt/KDE shared memory and semaphore support
- process-facing behavior such as `waitid()`
- networking/resolver completeness
- legacy but still-consumed items such as `sigjmp_buf` and locale/runtime edges
That means the right enhancement plan is no longer “finish one missing API and unblock everything.”
The work has to be triaged by downstream impact.
### 6. The Redox networking model is reflected in relibc
`recipes/core/relibc/source/src/platform/redox/socket.rs` shows a real Redox-native socket/path
model instead of a pure stub implementation. That is another strong point: relibc already knows
about Redox-native runtime behavior.
## Deficiencies and Gaps
### 1. Header coverage is still incomplete in visible source
`recipes/core/relibc/source/src/header/mod.rs` still contains a meaningful backlog of TODO or absent
header surfaces, including examples such as:
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`
@@ -281,379 +53,269 @@ header surfaces, including examples such as:
- `threads.h`
- `wordexp.h`
Some of these are lower-value than others, but they still show that relibc has real completeness work left.
The live source tree also still shows relibc areas that are **not** yet plain-source-complete:
### 2. Named semaphores are now source-visible, but still incomplete
- `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
`recipes/core/relibc/source/src/header/semaphore/mod.rs` is still a clear example of partial completeness.
That means older wording such as "now source-visible in the current tree" was too strong for much of
the current relibc surface.
Basic unnamed semaphore paths exist (`sem_init`, `sem_post`, `sem_wait`, `sem_timedwait`, etc.),
and the named semaphore path is now source-visible too:
### 2. The active relibc build relies on a broad patch chain
- `sem_open`
- `sem_close`
- `sem_unlink`
The active recipe in `recipes/core/relibc/recipe.toml` currently replays more than `redox.patch`.
The tracked patch list still includes, among others:
These are now implemented on top of the existing shm path instead of left as raw `todo!()` stubs.
- `redox.patch`
- `P0-strtold-cpp-linkage-and-compat.patch`
- `P3-eventfd.patch`
- `P3-signalfd.patch`
- `P3-signalfd-header.patch`
- `P3-timerfd.patch`
- `P3-waitid.patch`
- `P3-semaphore-fixes.patch`
- `P3-socket-cred.patch`
- `P3-elf64-types.patch`
- `P3-open-memstream.patch`
- `P3-ifaddrs-net_if.patch`
- `P3-fd-event-tests.patch`
The remaining weakness is semantic and validation depth, not pure absence:
So the active Red Bear relibc story is still **recipe-applied compatibility plus partial upstream
source**, not a nearly converged plain-source state.
- broader POSIX semaphore semantics are still not strongly runtime-validated
- downstream configure/runtime behavior still needs continued confirmation
- the SysV semaphore surface remains thinner than a full Unix implementation
### 3. What the active patch chain actually provides
This directly affects downstream consumers such as `QSystemSemaphore`.
Observed directly from the current patch set:
### 3. Shared memory is present, but not complete enough for downstream GUI/runtime work
- `P3-eventfd.patch`: adds `sys/eventfd.h` support through `/scheme/event/eventfd/...`
- `P3-signalfd.patch`: adds `signalfd` / `signalfd4` support through `/scheme/event` plus signal-mask handling
- `P3-timerfd.patch`: adds `sys/timerfd.h` support through `/scheme/time/{clockid}`
- `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-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` and `eth0`
- `P3-fd-event-tests.patch`: adds focused `eventfd`, `signalfd`, and `timerfd` tests
The current relibc source already exposes one meaningful shared-memory path:
This is meaningful progress, but it is still a patch-carried compatibility layer, not a finished libc
surface.
- `recipes/core/relibc/source/src/header/sys_mman/mod.rs` provides `shm_open()` and `shm_unlink()`
- on Redox, that path resolves to `/scheme/shm/`
- `recipes/core/base/source/ipcd/src/shm.rs` implements the backing shared-memory scheme
### 4. Fresh bounded-wave verification in this pass
That is a real strength and should not be described as “shared memory absent.”
This documentation pass also executed a fresh bounded relibc verification cycle against the active
recipe surface:
The real gap is that shared-memory completeness is still insufficient for broader downstream use:
- `./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`
- the source tree now has visible `sys/shm.h` / `sys/ipc.h` / `sys/sem.h` modules, but they remain bounded rather than comprehensive
- Qt/KDE-facing docs still treat `shm_open()` / `shmget()`-class behavior as unresolved enough to block full `QSharedMemory` confidence
- the current repo still lacks a strong end-to-end validation story for these paths in desktop consumers
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.
### 4. Resolver and interface-networking completeness are still uneven
## Quality assessment
The downstream scan shows that networking-facing userland still hits relibc gaps beyond raw socket
basics.
### Strong points
Examples from downstream recipes and docs:
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.
- `recipes/wip/qt/qtbase/recipe.toml` still leaves QtNetwork disabled because of broader networking/runtime concerns such as `in6_pktinfo` and richer interface semantics, even though minimal `resolv.h` and `arpa/nameser.h` surfaces now exist
- `recipes/net/openssh/recipe.toml` and its patch history still call out `resolv.h`
- `recipes/wip/terminal/tmux/redox.patch` comments out `resolv.h`
- `recipes/libs/glib/redox.patch` still touches resolver-facing includes
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.
### 5. The networking surface is narrower than generic Unix software expects
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.
The current source still shows important limits that should be named directly:
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/`.
- `recipes/core/relibc/source/src/platform/redox/socket.rs` has AF_INET / AF_UNIX socket handling
- `recipes/core/relibc/source/src/header/net_if/mod.rs` now exposes a bounded `eth0`-backed interface view instead of a permanent `stub`
- `recipes/core/relibc/source/src/header/ifaddrs/mod.rs` now provides a bounded `eth0`-backed `getifaddrs()` path instead of pure `ENOSYS`
- source-visible `resolv.h` / `arpa/nameser.h` plus bounded `res_query()` / `res_search()` compatibility are now present, and at least one real downstream (`openssh`) now builds against them, but broader resolver compatibility is still incomplete
### Weak points
That is enough to support the current Red Bear native network path in a bounded sense, but it is not
yet strong enough to claim broad interface-aware compatibility for higher-level consumers. Resolver/
header gaps and interface-model assumptions still show up in ports such as QtNetwork, OpenSSH,
tmux, glib, curl, and libuv.
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.
### 6. Process/runtime completeness is still uneven
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.
The repo still has process/runtime unevenness, but one meaningful consumer-facing gap has now moved:
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.
- relibc now provides a bounded `waitid()` implementation over the existing `waitpid` path
- the old Qt-side injected `waitid()` stub has been retired from the Qt recipe layer
## Completeness assessment
The source state needs to be classified carefully:
### Plain-source-visible gaps
- `sigjmp_buf` exists in `recipes/core/relibc/source/include/setjmp.h`, so older downstream comments treating it as absent are better read as compatibility/staleness signals rather than primary source truth
- `getgroups()` has a Redox implementation path in `platform/redox/mod.rs`
- `getrlimit()` is no longer a pure placeholder for all consumers: Red Bear now has bounded `RLIMIT_NOFILE` and `RLIMIT_MEMLOCK` behavior, but broader resource-limit completeness is still weak
Still absent or TODO in the live source tree:
So process/runtime completeness should be treated as a real subsystem-quality track, but the plan
must distinguish **missing**, **implemented but weak**, and **stale downstream complaint**.
- `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`
### 7. Source quality still contains many TODO / unimplemented branches
### Recipe-applied but bounded surfaces
The current source has a large amount of unfinished or explicitly deferred behavior across:
The active build surface includes several features that should be described as **bounded**, not
fully complete:
- `pthread`
- `time`
- `unistd`
- `platform/redox`
- `epoll`
- `ptrace`
- locale and stdio internals
- `timerfd`: the patch exposes `TFD_TIMER_CANCEL_ON_SET`, but `timerfd_settime()` only accepts
`TFD_TIMER_ABSTIME`
- `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
This does not mean relibc is unusable. It means completeness and quality work now needs a stronger
triage model instead of treating all missing items as equally important.
### Still-missing areas
### 8. Redox-target and downstream validation remain thin relative to subsystem importance
The clearest remaining gaps are still real gaps, not just "needs more runtime proof":
The current repo already contains a substantial generic relibc test tree, but the Red Bear-visible
validation story is still thin in the areas that matter most for current subsystem unblockers.
- POSIX message queues
- SysV message queues
- broader thread / spawn / iconv / wordexp completeness
Right now much of relibcs confidence in the Red Bear docs still comes from:
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.
- source inspection
- patch carriers
- build-side downstream success
- limited runtime validation via downstream stacks
## Robustness assessment
That is not enough for a component as central as libc, especially for the Redox-target and
downstream-consumer paths Red Bear depends on.
Robustness is the weakest part of the current relibc story.
## Downstream-Blocking Gaps by Subsystem
The repo now has a meaningful active patch-applied compatibility surface, but several pieces are
still narrow enough that the safest language is:
### Wayland
- useful for bounded downstream compatibility,
- not yet broad semantics-proof,
- and not yet safely describable as a plain-source upstream relibc completion story.
The old “basic POSIX APIs are missing” story is no longer the main one.
Concretely:
Current state:
- 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
- `signalfd`, `timerfd`, `eventfd`, `open_memstream`, bounded `waitid()`, key socket flags, and the adjacent SysV IPC surfaces are now source-visible in the active relibc tree without needing the old standalone P3 replay set
- the active Red Bear relibc replay has narrowed to the shared `redox.patch` compatibility delta while those older P3 files remain historical references
- `libwayland` now rebuilds with a much smaller Redox patch
## Recommended support language
Remaining blocker:
Use this language in project docs unless stronger evidence is gathered:
- runtime validation of the full relibc -> libwayland -> compositor path
- **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."
So the current relibc task for Wayland is primarily **runtime proof and patch reduction**, not just
adding obvious libc symbols.
## Improvement plan
Current Red Bear evidence is stronger than before: `libwayland` now cooks successfully against the
rebuilt relibc image produced from the current upstream-backed relibc tree plus the active shared
Red Bear compatibility delta, which means the `signalfd`, `timerfd`, `eventfd`, `stdio.h`, and
`sys/socket.h` surfaces are sufficient for at least one major downstream consumer in the current
rebuild model.
### Phase R0 — Keep the evidence model honest
### Qt / KDE
Goals:
The Qt/KDE-facing relibc backlog is still substantial.
- 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
The biggest libc-facing gaps are:
Exit criteria:
- shared memory (`shm_open` / `shmget`) for `QSharedMemory`
- named/system semaphores (`sem_open` / `semget`) for `QSystemSemaphore`
- stronger process/runtime behavior for `QProcess`
- runtime validation of QtNetwork against the current relibc networking surface
- resolver/header completeness (`resolv.h`) and network-interface semantics for QtNetwork
- broader process/runtime validation after the new bounded `waitid()` path
- relibc docs match the active recipe patch list
- repo-level summaries use bounded/evidence-qualified language
This makes Qt/KDE the clearest downstream consumer pushing relibc from “build-capable” toward
“desktop-capable”.
### Phase R1 — Make the active patch chain the explicit build contract
Current Red Bear evidence is stronger than before here too: qtbase now configures, builds, and
stages with
`FEATURE_process=ON`, `FEATURE_sharedmemory=ON`, and `FEATURE_systemsemaphore=ON` in the current
tree. The remaining work is therefore less about “make the feature visible at all” and more about
runtime semantics, broader compatibility, and downstream cleanup.
Goals:
### Networking and interface-aware software
- 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
The current relibc networking model is usable, but still narrow enough that higher-level consumers
keep carrying workarounds or disabled features.
Exit criteria:
The newer bounded `eth0`-backed `net_if` / `ifaddrs` work improves the source-visible story, but it
is still only a first Red Bear-shaped interface view, not a full generic Unix interface model.
- every relibc carrier still replayed by the recipe is documented as active
- every historical-but-not-active carrier is clearly marked historical
This is why the plan should treat networking as **usable but still validation-heavy**, not “done”.
### Phase R2 — Strengthen proof for the patch-applied surface
### General userland / server software
Goals:
The downstream scan also shows relibc gaps outside graphics:
- 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
- PostgreSQL and some libraries still carry `sigjmp_buf`-related downstream notes that need revalidation against current headers
- SQLite still notes `getrlimit()` / `getgroups()` gaps, even though the current source state now splits those two differently
- Apache and other ports still touch semaphore or IPC assumptions
Exit criteria:
That is important because it means relibc completeness is not only about desktop bring-up. It also
affects core application/server breadth.
- each active compatibility surface names its current proof level and missing proof
### Desktop/session path
### Phase R3 — Harden bounded compatibility layers
Session and desktop work depends less on one dramatic relibc gap than on overall libc quality:
Highest-value targets:
- process semantics
- IPC completeness
- synchronization primitives
- runtime interaction with D-Bus/Qt/Wayland consumers
- 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
This is why relibc should be treated as a cross-cutting runtime-quality subsystem, not just a POSIX checklist.
Exit criteria:
## Quality Assessment
- docs no longer need to caveat these areas as merely synthetic or narrowly bounded unless that
boundedness is intentional and accepted
### What relibc is good at now
### Phase R4 — Decide the real SysV IPC contract
- broad visible libc/header coverage
- practical Redox-native integration rather than fake stubs everywhere
- concrete P3 compatibility work for real downstreams
- enough maturity to unlock major subsystem builds
- a substantial generic test tree
The current bounded SysV shm/sem layer is better than raw absence, but it is not a broad final
design.
### What relibc is bad at now
Decision needed:
- uneven implementation depth
- too many TODO/unimplemented branches for a component this central
- patch-carried functionality that is still not strongly reflected in visible source snapshots
- too little Redox-target and downstream-runtime validation relative to the generic test tree
- too much downstream confidence still derived from “compiles” instead of “runtime-proven”
- either keep a clearly documented bounded compatibility contract,
- or implement a broader system-backed contract and test it accordingly.
## Enhancement Plan
Exit criteria:
### Phase R0 — Evidence and Ownership Cleanup
- the repo stops implying broad SysV completeness where only a narrow compatibility slice exists
**Goal**: Make relibc status honest before widening scope.
### Phase R5 — Triage the still-missing surfaces
**What to do**:
Priority candidates:
- explicitly track relibc claims as `source-visible`, `patch-carried`, `build-proven`, or `runtime-validated`
- keep the P3 patch carriers discoverable and documented as canonical until upstreamed
- stop describing relibc gaps with outdated “missing basics” language where the code already exists
- message queues,
- thread/spawn completeness,
- other TODO headers that block real consumers rather than theoretical completeness checklists.
**Exit criteria**:
Exit criteria:
- subsystem docs consistently distinguish between missing, patch-carried, and runtime-proven relibc behavior
- each remaining TODO surface is either implemented, explicitly deferred, or removed from misleading
summary language
---
### Phase R6 — Converge with upstream where possible
### Phase R1 — Stabilize the newly source-visible P3 APIs
Goals:
**Goal**: Keep the newly source-visible P3 APIs aligned with their patch-carrier and downstream expectations.
- shrink the relibc patch chain whenever upstream absorbs equivalent behavior
- avoid carrying Red Bear-local relibc deltas longer than necessary
**What to do**:
Exit criteria:
- keep `signalfd`, `timerfd`, `eventfd`, `open_memstream`, socket flags, and `F_DUPFD_CLOEXEC` visible and maintained as canonical relibc behavior
- reduce downstream assumptions that these APIs are still absent
- ensure generated/exported headers stay aligned with the source-visible implementation set
- the active recipe patch chain is smaller for evidence-based reasons, not for documentation optics
**Exit criteria**:
## Bottom line
- the repo consistently treats these P3 APIs as source-visible functionality that now needs validation and downstream cleanup rather than invention
relibc in the current Red Bear repo is neither a greenfield libc nor a nearly converged upstream
story.
---
### Phase R2 — Close the shared-memory and semaphore completeness gap
**Goal**: Unlock the next meaningful Qt/KDE-facing libc surface.
**What to do**:
- keep the existing `shm_open` / `/scheme/shm/` path explicit and documented
- implement the missing SysV IPC/shared-memory side or document a deliberate non-goal if Red Bear does not want full SysV compatibility
- harden and validate the now source-visible named semaphore support (`sem_open`, `sem_close`, `sem_unlink`)
- close the specific `QSharedMemory` and `QSystemSemaphore` blockers identified in the Qt docs
**Exit criteria**:
- the Qt/KDE docs no longer list shared memory and named semaphores as unresolved relibc blockers
---
### Phase R3 — Process/runtime correctness for desktop consumers
**Goal**: Reduce downstream process workarounds.
**What to do**:
- strengthen process-facing libc/runtime behavior enough to remove targeted workarounds such as the Qt `waitid()` shim path
- close or intentionally document the remaining `sigjmp_buf` / `getrlimit()` / `getgroups()` quality gaps that still force downstream patches
- validate process semantics against real downstream consumers, not only isolated libc expectations
**Current implementation note:** the bounded `waitid()` path is now source-visible, the old Qt-side
`waitid()` shim is gone, and qtbase now configures/builds/stages with process support enabled. The
remaining work is broader process/runtime validation and cleanup, not the old total absence of `waitid()`.
**Exit criteria**:
- downstream process workarounds are reduced or eliminated for the current desktop stack
---
### Phase R4 — Networking/runtime validation
**Goal**: Turn the current networking surface from “present” into “trusted”.
**What to do**:
- validate QtNetwork and similar consumers against the current relibc socket/ioctl/interface model
- close the highest-value resolver/header gaps such as `resolv.h` where they are still forcing downstream stubs or disabled modules
- evolve the new bounded `eth0`-backed interface-reporting path into a better general Redox interface model where needed
- document which current networking semantics are intentionally Redox-specific and which are intended to mimic broader Unix behavior
**Exit criteria**:
- at least one meaningful higher-level network consumer is validated against the current relibc networking surface
---
### Phase R5 — Dedicated relibc validation expansion
**Goal**: Improve libc confidence without waiting for whole desktop stacks.
**What to do**:
- build a stronger dedicated Redox-target and P3/downstream validation layer on top of the existing generic relibc test tree
- ensure new APIs and bugfixes come with focused libc-level tests where practical
- keep downstream consumer tests, but stop relying on them as the only quality signal
**Exit criteria**:
- relibc has explicit Redox-target and downstream-runtime validation beyond the generic upstream-style test tree
---
### Phase R6 — General completeness triage
**Goal**: Attack the remaining TODO/unimplemented backlog by priority rather than by random header count.
**What to do**:
- rank remaining TODO/unimplemented items by downstream subsystem impact
- prioritize IPC, synchronization, process, time, and networking correctness over obscure or deprecated headers
- keep deprecated/low-value gaps documented, but do not let them drive the roadmap ahead of higher-value runtime work
**Exit criteria**:
- relibc backlog is organized by real system impact instead of undifferentiated TODO volume
## Recommended Order of Work
The current best order is:
1. evidence cleanup and canonicalization of what already exists
2. shared memory and named semaphores
3. process/runtime correctness
4. networking/runtime validation
5. Redox-target and downstream validation expansion
6. broader backlog triage and cleanup
That order matches the current downstream blocker chain better than a generic “finish all missing headers” strategy.
## Support-Language Guidance
Until the runtime-validation phases are materially complete, Red Bear should avoid saying:
- “relibc POSIX gaps are solved”
- “Qt/Wayland blockers are fully gone”
- “network/process/shared-memory support is complete”
Prefer language such as:
- “consumer-visible P3 APIs are now present, with runtime validation still needed”
- “relibc is materially stronger, but desktop-facing completeness work remains”
- “the remaining relibc problem is now quality and downstream proof, not just symbol absence”
## Summary
relibc is one of Red Bears strongest foundational subsystems, but it is not complete.
Its strongest current qualities are:
- broad libc/header coverage
- real Redox-native platform integration
- concrete source-visible and patch-backed solutions to the historical P3 Wayland-facing blockers
- clear downstream build progress because of those fixes
- a substantial generic test surface
Its largest remaining weaknesses are:
- incomplete shared memory and named semaphore support
- process/runtime unevenness
- networking/resolver/interface completeness gaps
- too many TODO/unimplemented branches in central paths
- too little Redox-target and downstream-runtime validation relative to the generic test tree
The correct relibc roadmap is therefore **not** “hunt random missing symbols.” It is to turn the
current build-capable libc into a runtime-trusted subsystem by closing the high-value desktop/runtime
gaps, strengthening validation, and reducing patch-carried ambiguity.
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.