Per local/AGENTS.md Rule 2 (NO OVERLAY-STYLE PATCHES — AMENDED 2026), big
external projects must NOT have source forks in local/sources/. Mesa's
Red Bear edits now live as external patches in local/patches/mesa/,
matching the established pipewire and wireplumber migration pattern
(commits 8ff9da2ff, 722f0c452).
The 3 patches were recovered from git history (commit 89d1306c8^ —
the migration that deleted them) and renamed to the modern Rule 2
NN-prefix naming for lexical-order application:
01-virgl-redox-disk-cache.patch (P4 from old series, 49 lines)
02-gbm-dumb-prime-export.patch (P5 from old series, 56 lines)
03-platform-redox-gpu-probe.patch (P6 from old series, 264 lines)
These patches disable the virgl disk cache (dl_iterate_phdr is missing
on Redox), add the GBM dumb prime export for cross-GPU buffer sharing,
and implement the platform/redox GPU probe path needed for EGL/Vulkan
on Redox.
The recipe now points at upstream Redox mesa
(https://gitlab.redox-os.org/redox-os/mesa, branch redox-24.0) and
applies the patches via a git apply loop in [build].script with
correct path resolution (2 dots from recipes/libs/mesa/ to project root).
Fixes the broken state where the recipe referenced the now-deleted
local/sources/mesa/ fork.
The mesa recipe has been bouncing between direct-edit Wayland
configurations and the legacy Orbital EGL recipe. Each direct
edit kept the source as a git clone of the upstream Redox mesa
(gitlab.redox-os.org/redox-os/mesa, branch redox-24.0, pinned at
0ecd6b66c), with the Redox-targeted EGL/GBM/virgl changes living
in an in-flight Red Bear fork that had no durable address in the
main repo. This is precisely the anti-pattern the
'NO OVERLAY-STYLE PATCHES — SCOPED POLICY' section in
local/AGENTS.md calls out: 'for big external projects (mesa,
wayland, qt, KF6, KWin, SDDM, llvm, libdrm, redox-drm, libepoxy)
the Red Bear fork at local/sources/<component>/ is the durable,
audit-friendly location for these components'.
This commit completes the proper Red Bear full-fork model for
mesa:
* mainline recipes/libs/mesa/recipe.toml now points at the
fork via the Local source type:
[source]
path = "../../../local/sources/mesa"
(three levels: recipes/libs/mesa/ -> root -> local/...)
The cookbook's fetch.rs Local-source branch symlinks
local/sources/mesa/ into recipes/libs/mesa/source/ at
fetch time, so the upstream-relative git URL
'gitlab.redox-os.org/redox-os/mesa' is no longer needed
here.
* mainline recipes/libs/mesa/recipe.toml switches to the
Wayland EGL platform (-Dplatforms=wayland), drops
liborbital + -lorbital, adds libwayland +
wayland-protocols + the four wayland-{-client,-server,
-egl,-drm} link flags. The redox EGL platform
(src/egl/drivers/dri2/platform_redox.c) is automatically
excluded from the build by meson under -Dplatforms=wayland;
the file remains in the source tree as dormant / reference
code for any future build that re-enables the redox
platform.
* mainline recipes/libs/mesa/recipe.toml gets a [package]
section (version 0.2.3, description anchored on the
fork's 0.2.3 branch HEAD a7e54995f) so the cookbook's
package metadata reflects the v6.0 2026 release.
* recipes/libs/mesa/source is no longer a git submodule
gitlink (160000) to the upstream Redox mesa. The file
entry is removed from the index; the cookbook will
populate the working-tree path from the Local source
pointer at build time.
* local/recipes/libs/mesa/recipe.toml is removed. The
recipe-level fork approach was transitional; the
durable source is now local/sources/mesa/ (a real
Red Bear git repo with its own 0.2.3 branch, gitea
remote, and the upstream redox-24.0 branch left
intact for clean rebase-onto-upstream). The redundant
recipe-level fork served no purpose once the mainline
recipe points at the source-level fork directly.
* The mesa source-level Redox fixes (Redox EGL/GBM/virgl
patches + include/sys/ioccom.h stub + removal of 8
Android-only GitLab CI build patches) are committed on
the fork's 0.2.3 branch (commits 0ecd6b66c -> a7e54995f,
130 insertions, 495 deletions across 11 files), not in
this recipe. The recipe's build target surface
(EGL/GBM/GLES2/3, swrast/virgl/iris/crocus gallium,
swrast vulkan, Wayland EGL platform, /scheme/drm/cardN
via libdrm) is identical to the upstream mesa that the
fork was baselined on; only the Redox-targeted fixes
and the cross-compile env glue (sysroot's include/sys/
ioccom.h) diverge.
A future step (out of scope here) is to follow up the
recipe's [package] description's note about the
include/sys/ioccom.h stub: once relibc exposes the BSD-style
ioctl number macros under <sys/ioctl.h> directly, the
fork's include/sys/ioccom.h and the __redox__ guard in
include/drm-uapi/drm.h should both be removed, and the
fork's 0.2.3 branch should pick up the relibc change as a
forward rebase.
The header comment block of recipes/libs/mesa/recipe.toml
matches the same doc-contract used by
recipes/libs/libdrm/recipe.toml and
recipes/gpu/redox-drm/recipe.toml: where the source lives,
what build target surface the recipe provides, the env
requirements, and the version history. Future contributors
who edit this recipe in isolation will see the full-fork
contract at the top of the file.
The parallel-agent update completed the mesa recipe edit:
- Added full doc comment explaining the Red Bear fork model
- Switched to Wayland EGL platform (-Dplatforms=wayland)
- Replaced -lorbital with wayland-{client,server,egl,drm} link flags
- Added [package] section with version + description
- Removed liborbital dep; added libwayland + wayland-protocols
Per AGENTS.md Rule 2 (amended 2026), mesa is a big external
project (multi-million-line codebase) and is maintained as a
Red Bear fork at local/sources/mesa/. The recipe in mainline
is a thin shim that points the cookbook at the fork.
This is a direct edit of the mainline recipe, NOT an overlay
symlink. The cookbook now walks local/recipes/ first (commit
d747b4009), so the mainline recipe is the authoritative source
of truth for the Red Bear fork.
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 Red Bear OS forks of libxkbcommon and xkeyboard-config under
local/recipes/, replacing the previous WIP overlays. The local recipes
build against the XKB data and ship meson flags consistent with the
WIP-recipe baseline. The recipes/wip/ symlinks are kept so existing
config/ includes that reference the WIP path keep working.
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.
Revert the mesa pointer bump to d73234bf because the underlying
git objects are not reachable from any current repository. The
mesa source directory at recipes/libs/mesa/source was destroyed
mid-task (likely by build-redbear.sh re-creating local/recipes
symlinks), so the .git directory backing the original commit is
gone. Without those objects the new pointer is dangling.
This reverts fd5f84e6c and restores the recipes/libs/mesa/source
pointer to the original recorded value 0ecd6b66c, matching the
pre-task state. The Redox EGL/GBM/virgl fixes that were captured
in fd5f84e6c must be re-derived from the working tree once mesa's
source is re-fetched from the upstream gitlab URL recorded in
recipes/libs/mesa/recipe.toml.
Follow-up: re-create recipes/libs/mesa/source as a real git clone
of https://gitlab.redox-os.org/redox-os/mesa.git at branch
redox-24.0, replay the platform_redox.c / gbm_dri.c /
virgl_screen.c edits plus the include/sys/ioccom.h stub, and
re-cut the pointer bump.
Pick up the mesa fork's 0.2.3 branch HEAD (d73234bf), which rolls
up a set of bounded Redox-targeted changes:
EGL/Redox platform (src/egl/drivers/dri2/platform_redox.c):
real __DRIimageLoaderExtension implementation
(redox_image_get_buffers, redox_hw_flush_front_buffer), front/back
buffer image plumbing on window surfaces, dri_image_back lifecycle
hooked into redox_free_images, visual set from the pbuffer config,
and a redox_probe_device_hw path that publishes the new extension
set. GBM dumb-prime path (src/gbm/backends/dri/gbm_dri.c): fall
back to drmPrimeHandleToFD on the BO handle for get_fd when no
dri image is attached, and reuse that path from get_plane_fd for
plane 0 on dumb BOs. Virgl disk cache (src/gallium/drivers/virgl/virgl_screen.c):
disable the disk shader cache on Redox because the cache init
path goes through build_id_find_nhdr_for_addr -> dl_iterate_phdr
which is not available on Redox. Build environment: add
include/sys/ioccom.h providing BSD-style _IO/_IOR/_IOW/_IOWR
aliases on top of <sys/ioctl.h> for Mesa's DRM uapi headers, and
remove the eight .gitlab-ci/container/patches/build-*.patch
Android/deqp/skqp patches that only apply under Mesa's GitLab
container CI.
Pick up the llvm21 fork's 0.2.3 branch HEAD (1737762446), which
removes the libfbsdvmcore-hacks and lldb-minimize-processes
patches under lldb/test/API/functionalities/postmortem/FreeBSDKernel/tools.
Those are upstream CI patches for LLDB's FreeBSD kernel core-dump
testing infrastructure; they are not part of the upstream test
suite, are not applied anywhere in the build, and are not used
by Red Bear. Removing them keeps the source tree in sync with
what LLDB actually needs to build and prevents future code search
from surfacing them as in-flight Red Bear work.
The redbear-full desktop target now pulls in pipewire and wireplumber
as the audio backend for KDE Plasma (Phonon, KMix, the Plasma audio
widget). This wires up the packages built by the new
local/recipes/libs/pipewire and local/recipes/libs/wireplumber
recipes on top of the existing audiod scheme daemon in the base
package.
Changes:
* config/redbear-full.toml
- new [packages] entries for pipewire and wireplumber
- two new [[files]] init services: 15_pipewire.service and
16_wireplumber.service (both oneshot_async, depend on
12_dbus.service)
* local/recipes/system/redbear-dbus-services/files/
- new org.freedesktop.PipeWire.service (system bus, runs
/usr/bin/pipewire) and org.pulseaudio.Server.service
(system bus, runs /usr/bin/pipewire-pulse)
- new org.freedesktop.impl.pulseaudio.service (session bus,
runs /usr/bin/pipewire-pulse) for KDE Phonon / KMix
- matching .conf policy files for org.freedesktop.PipeWire
and org.pulseaudio.Server that allow the expected
Introspectable / Properties / *Manager / *Node / *Link /
*Client / *Device / *Meter / *Core / *Port send and
receive patterns
* config/protected-recipes.toml
- new [libs] entries for pipewire and wireplumber, so the
cookbook never silently re-fetches them; sources are
directly editable in local/sources/
* recipes/wip/services/{pipewire,wireplumber}
- replaced the tracked WIP directories with symlinks to
local/recipes/libs/{pipewire,wireplumber}, per the
local-over-WIP convention enforced by
local/scripts/build-redbear.sh
Known build state (documented in the upstream README-redbear.md
files in each source fork):
* pipewire build reaches ~24/603 C files compiled before
hitting relibc gaps (sys/prctl.h, sys/mount.h, and a few
Linux-specific ioctls). The recipe, source fork, and
Redox-compat shims are in place; the remaining work is
upstream relibc headers, not PipeWire porting decisions.
* wireplumber recipe is in place but the build has not been
attempted yet — wireplumber depends on the pipewire build
completing first.
The audiod integration (the scheme backend that pipewire would
talk to) is not implemented in this commit. That is the next
gating work item and is tracked in
local/sources/pipewire/README-redbear.md.
The v6.0 single-producer input architecture registers the input
producer scheme as 'input/evdev' (not the legacy 'input' scheme).
Without this update, the initfs would try to register 'input' but
the inputd binary would attempt to register 'input/evdev' — leading
to a 'scheme already registered' error or a missing scheme entirely.
Also update the description to reflect the v6.0 role: pure evdev
ring buffer (not the legacy VT input and graphics multiplexer).
The libudev-stub was a real 1314-line libudev implementation backed
by the /scheme/udev producer (driven by udev-shim) — not a stub in
the zero-tolerance sense. It was named -stub to make the bounded
hotplug-event-delivery scope obvious.
Rename the recipe to libudev to match the upstream systemd surface it
implements (the recipe still backs through scheme:udev, but the public
name now matches the library's actual role for KWin tablet / input
discovery and libinput's udev device enumeration). Update:
- local/recipes/libs/libudev/recipe.toml: bump to 0.2.3, drop the
#TODO: stub-style header, add v6.0 2026 description
- local/recipes/libs/libinput/recipe.toml: dependency now 'libudev'
- local/recipes/kde/kwin/recipe.toml: dependency now 'libudev'
- config/protected-recipes.toml [libs]: now lists 'libudev'
The libudev.pc, UDev::UDev CMake target, and libudev.so surface are
unchanged — they are the real libudev C ABI as required by KWin and
libinput, with /scheme/udev/devices as the data source.
The lcms2-stub was a CMake-imported shared library that returned
NULL/zero from every API: cmsOpenProfileFromMem, cmsCreateTransform,
cmsDoTransform, cmsCreate_sRGBProfile, cmsGetProfileInfo, and the
rest. KWin color correction, ICC profile lookup, and color space
transformation were silently broken — every transform call produced
identity output.
Replace it with the real lcms2 (mm2/Little-CMS lcms2.19 fork) — the
full upstream C source built via CMake, providing real profile
parsing, gamut mapping, ICC v4 / v2 profile handling, sRGB profile
generation, and the LittleCMS transform pipeline. Recipe bumped to
0.2.3 with v6.0 2026 description.
The libdisplay-info-stub was a bounded 11k shim that parsed only base
EDID vendor/product, strings, physical size, chromaticity, and the
preferred-timing descriptor. All other di_edid_* / di_cta_* /
di_displayid_* calls returned NULL or fell through to the stub.
KWin output configuration, display detection, and EDID-based
connection setup were silently degraded.
Replace it with the real libdisplay-info (emersion/libdisplay-info
fork) — a full C implementation that exposes the libdisplay-info
EDID parser API (di_info_parse_edid, di_edid_get_vendor_product,
di_edid_get_display_name, di_edid_get_screen_size, etc.) with
complete EDID 1.4 parsing of base block + extensions. CTA and
DisplayID remain unsupported in the bounded v6.0 2026 fork, which
is documented in the [package] description. Recipe bumped to 0.2.3.
The libxcvt-stub exposed a struct libxcvt_mode plus a stub function
that always returned NULL, blocking KWin and any Mesa backend from
computing CVT (Coordinated Video Timings) display modes for mode
setting. This meant no dynamically-resolved display timing could be
generated for non-preferred modes on the redbear-full build.
Replace it with the real libxcvt (freedesktop.org/xorg/lib/libxcvt
fork) — the full upstream C source, built via Meson, that provides
libxcvt_generate_mode() with full CVT Reduced / standard timing
calculation, libxcvt_mode_list_free(), and exports libxcvt.pc plus
the proper include path. Recipe bumped to 0.2.3 with v6.0 2026
description.
The libepoxy-stub provided a hardcoded stub that returned 0/NULL for
every epoxy_egl_extension_supported, epoxy_has_gl_extension, and
epoxy_gl_version call, plus a fake epoxyConfig.cmake. KWin and Qt6
Wayland code paths were never able to detect GL/EGL extensions or
negotiate GL versions, which broke the KWin rendering pipeline silently.
Replace it with the real libepoxy (anholt/libepoxy fork) — the full
upstream C source, built against Mesa EGL/GLES2, that registers
epoxy::epoxy in CMake, provides libepoxy.pc, and produces the real
epoxy_gl_version / epoxy_has_gl_extension / epoxy_egl_*_supported
runtime values. Recipe bumped to 0.2.3 with v6.0 2026 description.
Also: protected-recipes.toml [libs] no longer lists the stub.
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.
- Complete PCI enumeration (class 0x0C, subclass 0x03, prog-if 0x00)
- I/O port register access (inb/outb style via volatile ptr)
- BAR4: I/O port range for operational registers (USBCMD, USBSTS, etc.)
- MMIO-mapped FLBASEADD for frame list base address
- 1024-entry frame list with QH pointers
- Control QH chain for transfer scheduling
- Full controller reset and initialization sequence
- Port polling with connect/disconnect detection
- Device enumeration via control transfers (GET_DESCRIPTOR, SET_ADDRESS)
- Port reset with proper timing (50ms hold, 10ms settle)
- Transfer descriptor (TD) construction for setup/data/status phases
- Wait-for-completion loop with error detection
- All registers documented in registers.rs per UHCI spec
- Scheme interface for scheme:usb access
On Redox there is no udev-based DRM device enumeration. KWin's DRM
backend relies on m_udev->listGPUs() which returns nothing without udev.
Add a fallback: when no KWIN_DRM_DEVICES is set and the session is
kde-wayland, inject KWIN_DRM_DEVICES=/scheme/drm/card0 so KWin knows
which device to open. This fixes the 'No suitable DRM devices' error
that prevented KWin from starting on Redox.
Added test: build_environment_sets_kwin_drm_devices_default_for_kde_wayland
to verify the fallback is applied correctly.
Per AGENTS.md policy: local recipes ALWAYS supersede WIP packages.
Any WIP directory that shadows a local/recipes/ package is replaced
with a symlink to the local version.
Fixed shadows: bison, flex, m4, meson, ninja-build, libxcvt,
qt6-sensors, libepoxy, mc — all now symlinked to local/recipes/.
Added WIP-local enforcement to build-redbear.sh: auto-detects and
fixes WIP shadows at build time.
Extract protocol-agnostic FenceTimeline from Intel to shared
src/drivers/fence.rs — atomic-based fence tracking suitable
for Intel, VIRGL, and AMD drivers.
Extract protocol-agnostic SyncobjManager from Intel to shared
src/drivers/syncobj.rs — syncobj create/destroy/signal/reset/
wait/query and sync_file fd export/import.
Wire both into VirtioDriver:
- Add FenceTimeline + SyncobjManager fields
- Implement all 5 GpuDriver syncobj trait methods
(create, destroy, wait, export_fd, import_fd)
- Track fence seqnos in virgl_submit_3d (allocate
before submit, signal after completion)
Intel fence.rs and syncobj.rs converted to thin re-export
modules pointing at shared sources — no behavioral change
for Intel driver.
This gives Mesa VIRGL userspace the standard DRM syncobj
API for GPU/compositor synchronization.
The WIP recipes/wip/files/mc had an empty recipe.toml (0 bytes),
causing the cookbook to report 'successful' without producing any
output. Replaced with a symlink to the real recipe at
local/recipes/tui/mc which has the full build configuration.
Also fixed the recipe: removed broken cookbook_configure call
(which was cached from a previous failed attempt), replaced with
explicit configure+make+make install. Added gl_cv_list_mounted_fs=yes
since Redox has no /etc/mtab or /proc/mounts.
Passes the current Unix timestamp as BUILD_TIMESTAMP env var
to cargo, so rtcd can use it as a fallback when the hardware
RTC is unavailable or returns invalid data.
bison: fix __fseterr stub injection using LIBS variable instead
of ar rcs to avoid static archive member ordering issues.
- Fix bootloader recipe: pass correct TARGET on make command line
instead of hardcoding x86_64-unknown-uefi (breaks BIOS build)
- Add cargo -Zunstable-options to x86_64-unknown-uefi.mk and
x86-unknown-none.mk for custom target support
- Add x86_64-unknown-uefi.json target file
Remaining: redoxer toolchain cargo/rust-src version mismatch
prevents build-std compilation. Needs 'make prefix' to rebuild
toolchain with matching versions.
Bootloader needs x86_64-unknown-uefi (UEFI target) but redoxer
sets TARGET=x86_64-unknown-redox (OS target). Added:
- x86_64-unknown-uefi.json custom target file
- cargo -Zunstable-options in Makefile for custom target support
- TARGET= override in recipe (may still be overridden by redoxer)
Root cause chain discovered and fixed:
1. GCC built-in stddef.h shadowed by relibc's _STDDEF_H guard
→ fix_types.h with guarded typedefs for 15+ sys types
2. gnulib configure bakes raw typedefs into GL_CFLAG_GNULIB_WARNINGS
→ strip them from Makefiles after configure
3. __fseterr/__freadahead don't exist in relibc
→ compile C stubs and inject into link via Makefile patch
The recipe pattern is documented and reusable for other gnulib packages
(ninja-build, diffutils, etc.).
Also: bootloader recipe needs RUSTFLAGS=-Zunstable-options for
custom target support after redoxer toolchain restore.
Root cause: gnulib configure bakes raw typedef statements
(typedef long unsigned int size_t; etc.) into the generated
Makefile's GL_CFLAG_GNULIB_WARNINGS variable. These break
shell command parsing when expanded on recipe lines.
Fix:
1. Strip raw typedefs from all generated Makefiles after configure
2. Provide fix_types.h with guarded typedefs for size_t, ptrdiff_t,
off_t, wchar_t, ssize_t, time_t
3. Force-include fix_types.h via CPPFLAGS to work around the
cross-compiler's GCC built-in stddef.h ordering issue
Also: comprehensive upstream relibc comparison and import plan
Lines 649-651 had VramManager and info!() calls that don't belong
in handle_irq(). These were likely from a bad merge. The variables
fb_phys and fb_size are local to new() and don't exist in handle_irq().
Add pcid-spawner to initfs binaries for early boot driver spawning.
Add pcid.d/00-storage.toml with initfs-path driver commands.
pcid-spawner uses the channel protocol which works; driver-manager
hangs on pcid config handle reads.
Fix 4 E0277 errors in daemon/src/lib.rs where scheme_root()
and create_this_scheme_fd() return syscall::error::Error but
the function returns syscall::Error. Add .map_err() conversions.
redox-driver-sys errors (6 remaining E0308/E0061 in dma.rs/io.rs)
are pre-existing API mismatches between libredox and redox_syscall
crate versions — not addressed here.
- Create source symlinks for all 7 core components (kernel, relibc, base,
bootloader, installer, redoxfs, userutils) pointing at local/sources/
- Create redoxfs and userutils fork repos from frozen 0.1.0 archives
- Fix relibc-tests recipes: replace patch commands with direct fork build
- Archive all 417 patch files to local/archived/patches-2026-06-migration/
- Full AGENTS.md rewrite: remove all 31 remaining stale patch references,
update DURABILITY POLICY to describe git commit workflow, update WHERE TO
LOOK table, fix build flow description, replace Recipe Patch Wiring section
with Recipe Source Configuration
- Zero active patches = [...] arrays remain in any recipe.toml file
- All 13 remaining grep hits for 'patches' are TODO comments in WIP recipes
userutils compiled redox-rt with default-features=false, disabling the proc feature. This caused login's fork to not pass proc fd to child shell, triggering assertion failed: info.has_proc_fd in redox-rt. P8 patch enables features=['proc']. Verified: zero panics on boot, login works for user/root.
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Replace all 9 kernel uid==0 privilege checks with a capability bitmask
model. Adds caps:u64 field to Context and CallerCtx, with CAP_ALL for
root processes. Zero behavioral change - uid==0 still gets all caps.
New module: src/scheme/caps.rs with 10 capability constants.
9 check sites converted: acpi, irq, memory, debug, serio, sys (msr+write),
scheme registration, and fchown.
Patch: local/patches/kernel/P27-capability-bitmask.patch
vasilito
Kellito