NextBSD Research

NextBSD

• A cross-built nextbsd-userland repo — split the Apple stack out, slim nextbsd to an ISO assembler Plan ready Move NextBSD's ~2,260 lines of in-chroot Apple-userland compilation out of nextbsd/build.sh into a new nextbsd-userland repo that cross-compiles on a Linux host (like nextbsd-freebsd-compat), publishes a 4th rolling continuous artifact, and drops the in-image build toolchain (cmake/ninja/pkgconf/llvm19) entirely — leaving nextbsd a thin assembler (download 4 tarballs → layer → uzip → ISO, ~3,245→~700 lines). From a 3-agent scope. Key feasibility wins: only 2 components are CMake (libdispatch, swift-foundation-icu); the other 18+ are bsd.lib.mk Makefiles that cross-compile in make.py buildenv with zero source changes. The real work is harness-level: stage the sysroot from compat's continuous, relocate two build-time runs of cross binaries (test_corefoundation/kextdeps) to the boot-test, replace ~26 chroot ldd/ldconfig checks with readelf, and write 2 CMake cross-toolchain files. Phased rollout (parallel non-cascading → dual-source flag → flip cascade → delete) keeps the green chain intact.
• FreeBSD-compat 3-way audit — what we install, overwrite, and could port from Apple Audit Every one of the 99 components the nextbsd-freebsd-compat closure installs into the NextBSD base (srclist.txt), cross-referenced against (1) what NextBSD overwrites with Apple-sourced code and (2) what could be ported from Apple open source instead — each with a port-difficulty rating (Trivial→Impractical). From a 4-agent audit. Headlines: 0/99 currently overwritten (Apple's reboot/shutdown/login/su/mtree are vendored from system_cmds/shell_cmds/file_cmds but deferred behind IOPMLib/BSM shims); libbsm already is Apple's OpenBSM; the UFS tooling (newfs/tunefs/fsck_ffs) is Impractical because Apple has no UFS code (only newfs_hfs/apfs); the libc/loader ABI is Mach-O-incompatible; and krb5 is MIT (not Apple's Heimdal), so that “easy Apple port” doesn’t exist.
• Drop CI caching & purge caches across the build chain Plan ready Remove every caching layer from the nextbsd-redux build chain (ccache in kernel/compat/modules, the distfiles cache in nextbsd, the Docker BuildKit GHA layer cache in nextbsd-kernel-toolchain) via direct commits in build-chain order, then purge the stored caches. From a 3-agent investigation with a key correction: dropping ccache is not just deleting the cache step — each make.py wires the cache in via --cross-bindir=${CCACHE_CROSS_BINDIR}, so every call must be repointed to ${CROSS_BINDIR} (the real Clang 19) or the build rebuilds its own LLVM. And the premise correction that matters: the “freebsd-version stuck at 15.0” symptom was not a ccache replay (the kernel sets RELEASE to a timestamp and keeps REVISION stock at 15.0 by design, so vers.c always misses) — it came from a stale baked GHCR toolchain image plus genuine version pins (nextbsd-kernel-modules on releng/15.0, build.sh default 15.0), none of which a cache purge touches. Cache-drop buys determinism; the version fix is the toolchain-image refresh + the 15.1 base bump.
• NextBSD graphics — bumping drm-kmod 6.6 → 6.12 (and the 15.1 gate) Decision plan Can we move the Intel/AMD/Radeon kexts to the Linux-6.12 DRM backport, and do we need FreeBSD 15.1? A three-agent review of the ports tree, freebsd-src LinuxKPI, and the NextBSD graphics build. Answers: (1) yes, graphics/drm-612-kmod exists (DRM from Linux 6.12 LTS, 6.12.85); (2) yes, 15.1 is mandatory — the port hard-requires __FreeBSD_version ≥ 1500509 and NextBSD’s releng/15.0 (1500068) is excluded by the port’s IGNORE clause and lacks the 6.12 LinuxKPI symbols (fd_file(), fop_flags, the <linux/unaligned.h> move, 6.12 kvrealloc(), expanded folio/dma-mapping/xarray) present on 15.1 and absent from 15.0; (3) the kext bump itself is a one-line --branch 6.6-lts→6.12-lts flip + FW_TAG bump, but it’s gated on moving the kernel base 15.0→15.1 (pkg ABI FreeBSD:15 preserved). Covers NextBSD’s current build (drm-kmod 6.6-lts, baked LinuxKPI, per-vendor firmware bundling), the decoupled date-versioned gpu-firmware, the 6.6→6.12 hardware delta (Meteor/Arrow Lake i915, newer amdgpu — but still no Xe2 / Battlemage / Lunar Lake), a sequenced two-ticket plan, and the baked-MODULE_DEPEND/firmware-size risks.
• NextBSD — executing the releng/15.1 bump & drm-kmod 6.12 (per-repo runbook) Execution plan The execution follow-on to the decision plan above: it takes the verdict as settled (drm-612-kmod hard-requires __FreeBSD_version ≥ 1500509, so releng/15.1 is mandatory, pkg ABI FreeBSD:15:amd64 preserved) and answers exactly what to change, in which repo, in what order, and what to verify for issues #336 (base 15.0→15.1) and #337 (graphics kexts 6.6→6.12 + firmware). From a six-agent scope of the whole build chain: the dispatch topology, per-repo scope across the six nextbsd-redux repos (freebsd-src sync fork, nextbsd-kernel-toolchain, nextbsd-kernel, nextbsd-kernel-modules where both tickets land, nextbsd-freebsd-compat, and the nextbsd ISO assembler), a seven-step ordered runbook (sync → manual checkpoint → toolchain → kernel → base → kext bump → assemble & boot-test), a ranked risk register, and acceptance criteria mapped to the tickets.
• NextBSD input & touch drivers — hms vs utouch spike Research / spike A four-agent code review of freebsd-src and wulf7/utouch answering whether choosing hms over utouch loses any device support — no: same author, hms is the in-base successor and a strict superset (relative + I2C mice plus the absolute VM-tablet pointers utouch existed for), and utouch’s own README says “deprecated on 13+, use hms(4).” The historical “base didn’t work” pain was a default-OFF config (hw.usb.usbhid.enable) flipped ON in 15.0, not a missing driver. Covers why NextBSD must compile in the leaves (no .ko tree to auto-load — GENERIC ships only the keyboard leaves + transports), the hms/ums mouse path with absolute-axis handling and the sysmouse/HUG_TWHEEL/INPUT_PROP_DIRECT gaps, the touch/touchpad/pen stack (hmt/hpen/iichid+ig4/ietp/hconf, with IICHID_SAMPLING mandatory on amd64), QEMU/KVM (USB tablet works, no native virtio-input guest driver), Microsoft Surface (IPTS/ITHC/SAM — won’t work in base), Lenovo ThinkPad I2C-HID + PS/2 TrackPoint, the import timeline (D27777 → 13.0 → 15.0 default-on), and the exact config/NEXTBSD lines to bake in. Background for issue #335 / PR nextbsd-kernel#46.
• NextBSD unionfs inode-collision fix — design plan Design / proposal Permanent kernel-side fix for issue #332: the live unionfs root gives every layer the same st_dev and passes underlying inode numbers through, so an upper-layer header and an unrelated lower-layer header collide on (st_dev, st_ino) — and clang, which keys #pragma once/#import/include-guard dedup on file identity not path, silently skips the second (the GS_EXPORT / cups_lang_t / OBJC_PUBLIC / encode_NSInteger failures, none reproducible on stock FreeBSD). No clang flag can fix it (upstream LLVM calls it a filesystem bug). Fix modelled on Linux overlayfs xino: keep one st_dev, reserve the high bit of the 64-bit fileid as a layer tag in unionfs_getattr(), mirror it onto d_fileno in unionfs_readdir() (two layers ⇒ collision-free by construction). Exact union_vnops.c/union.h touch points, alternatives (per-layer st_dev, separate build FS, the inode-bust sweep), a full risks & implications section (32-bit ino_t EOVERFLOW, readdir bounce-buffer cost, copy-up churn, ZFS bit-63 exhaustion, NFS export), a deliberate-overlap kyua regression test + collision detector, and rollout. Retires the inode-bust build-script workaround.
• Why a live ISO won’t boot under Ventoy / iPXE — the initramfs research Research Why the FreeBSD ISO fails under Ventoy/iPXE (and sometimes real hardware): the bootloader–kernel handoff wall — /dev/iso9660/<LABEL> is created by the kernel after the loader has handed off and exited, so swapping bootloaders (GRUB, Apple’s boot-132) can’t help, and at ExitBootServices the firmware Block I/O dies (amd64 long mode can’t call INT 13h either). Two physics classes: real block devices (CD/DVD/dd-USB/VM — work, modulo discovery timing) vs. firmware-emulated/fragmented media (Ventoy/iPXE/MEMDISK — the kernel can’t re-reach them). How Linux actually fixes it — the initramfs, not a mounted ISO: reconstruct from the real stick (exFAT loop-mount / dm-linear) for Ventoy, network-fetch (dracut livenet / casper netboot=url / NFS / iSCSI+iBFT) for iPXE. The NextBSD equivalent: mfsroot+/init is the initramfs — turn /init into an ordered probe. Includes the geom_ventoy (BSD-2-Clause) / exFAT-gap / isboot assessment, a phased plan, and the single-user disambiguation test for real hardware. Background for #288.
• NextBSD Server Installer — dialog-based installer design Design doc Screen-by-screen design for a text-mode, dialog-driven server installer — amber-on-black TUI mockups for each phase rendered as illustrative box-drawing renders. Flow: Install / Upgrade (Upgrade gated until an existing install is probed), whole-disk selection showing volume labels + filesystem type broken out per disk (not just device ids), account + hostname (username/password/confirm with a hostname auto-suggested as joe-thinkpad-t460 from username + DMI model, still editable), a cpdup clone progress gauge (live filesystem cloned to the destination volume, no archive extraction), and a finish screen with Reboot / Shutdown. Build identity follows the continuous rolling release (timestamp + short commit). Includes the hostname-derivation logic, disk-column source mapping, and a palette/visual-language reference for a bsddialog(1) / ncurses implementation.
• NextBSD CI Pipeline Plan Live Automated FreeBSD cross-build pipeline on GitHub Actions free-tier Linux runners: daily fork sync, Docker-layered toolchain containers on GHCR, kernel/modules/base cross-builds, and the nextbsd ISO assembler. Targets releng/15.0 for pkg ABI compatibility; zero self-hosted runners, no open ports. Now live end-to-end and refactored around rolling, CI-gated continuous releases (producers publish on green main; consumers ingest the release, never in-flight PR artifacts), with PR validation on every repo, arm64 base parity, and a PR-only kernel boot smoke test. See §0 for the June 2026 status.
• Gershwin on NextBSD — build & live-ISO pipeline Design plan How the (currently empty) pkgdemon/gershwin-on-nextbsd repo grabs the latest NextBSD .img.zip, builds the Gershwin desktop into its rootfs, and repackages the result into a live ISO that boots identically to NextBSD’s own — 2-stage MFS, on-demand uzip, unionfs, and vfs.pivot. Covers why the repackage must run inside a FreeBSD VM, the repo layout, the build-iso.yml pipeline and live-ISO repackage stage, and the three launchd services (loginwindow, dshelper, gdomap) the desktop overlay must ship.
• gershwin-developer — NextBSD build CI (vmactions chroot) Plan Add a fourth build target to gershwin-developer’s build.yml — alongside FreeBSD, Arch, and Debian — that verifies Gershwin compiles on NextBSD. The trick earlier lacked: don’t boot the NextBSD image, chroot-build into its rootfs inside a FreeBSD VM. Documents where the job fits in build.yml, the one make-or-break risk, and what the check does and doesn’t prove. The job scrapped two iterations ago, now actually feasible.
• NextBSD — cross-build the Apple userland + image on native Linux Single-PR plan Move the NextBSD image build off the vmactions/freebsd-vm qemu VM (~17 min) onto a native Linux runner that cross-compiles the entire Apple/Darwin userland for FreeBSD with Clang 19 — zero FreeBSD packages, no chroot, the bootable UFS image assembled on Linux, qemu used only to boot-test (which already runs on ubuntu). Reuses the proven cross-build pattern from nextbsd-kernel-toolchain / -kernel / -kernel-modules / -freebsd-compat. Component-by-component plan for all 32 src/ components + mach.ko, the two net-new CMake toolchain files (libdispatch, ICU), Linux image assembly (makefs/mkimg), and a boot-contract parity oracle. Unlocks a faster arm64 ISO as a free matrix leg.
• NextBSD CI — testing coupled cross-repo changes (strategy options) Decision plan Backbone shipped How to boot-test changes that span two repos before either merges — motivating case: a nextbsd-kernel PR raising the dynamic syscall-slot limit plus a nextbsd PR dropping mach.ko’s syscall multiplexor. Visual comparison of five strategies (continuous-release + latest-green pin, artifact-override inputs, full monorepo, partial monorepo, hybrid integration meta-workflow) with a per-stage time-to-test cost model across today’s VM and native-cross worlds, a ratings matrix, and a NOW-vs-after-crossbuild recommendation. Confirms 5 current CI gaps (no PR triggers / no kernel boot test / latest-main-only ingest / a modules patch-ref desync / arm64 asymmetry).
• mach.ko syscall slots — implementation plan (widen the band, drop the mux) Plan ready Now that NextBSD ships its own kernel, the fix for the 10-slot Mach syscall ceiling is to widen FreeBSD’s lkmnosys band in the NEXTBSD kernel (a syscalls.master patch in nextbsd-kernel) so each Mach trap gets its own slot and the multiplexor goes away. Measured need ~32 slots; provision ~48. Includes a measured effort-scope of the XNU-style separate trap table (the kernel hook is a cheap C-only change, but first-of-its-kind on FreeBSD and its Apple-canonical-number benefit is moot because libmach resolves by name), and confirms IOKit needs no XNU libsyscall. Two-PR rollout: widen the band, then drop the mux. Supersedes the audit spike’s “kernel-patch disqualified” verdict.
• IOKit busyState / waitQuiet — implementation plan (Apple-shape kmod autoload) Plan ready The “right way” to drive kmod autoload: a real device-quiescence signal (IOServiceWaitQuiet / IORegistryEntryGetBusyState / IOKitWaitQuiet) over Mach, replacing FreeBSD’s devctl-plus-a-timer heuristic. A balanced device_match_start/device_match_end hook wrapping device_probe_and_attach() in the NEXTBSD kernel feeds a mach.ko bus_busy counter + a mach_wait_quiet syscall; hwregd flips on quiescence and libIOKit implements the Apple APIs. Makes concrete (and corrects the counter design of) the deferred plan in the #67 options doc, now that NextBSD ships its own kernel. Tracked by #176; two-PR rollout like the syscall work.
• FreeBSD .ko → Apple .kext conversion Plan Convert NextBSD’s kernel modules from FreeBSD .ko to Apple .kext bundles in /System/Library/Extensions — the Apple-shaped format, established before the kextd loader port. Code-grounded 3-agent scope: a .kext bundle wraps the unmodified .ko (still kld-loaded), Info.plist IOKitPersonalities generated from MODULE_PNP_INFO feed the userspace matcher NextBSD already has (libIOKit→hwregd); a full XNU OSKext is explicitly out of scope (the path ravynOS left FreeBSD for). Includes the firmware answer (gpu .ko-firmware vs wifi /boot/firmware → Contents/Resources) and the boot-critical caveat. Novel — nobody packages .ko as .kext today.
• Eliminating standalone hwregd — Apple-shaped device matching & autoload Convergence plan How to retire NextBSD’s standalone devctl-socket + timer hwregd daemon and converge toward Apple’s shape — in-kernel matching + match-notifications & busyState/waitQuiet over Mach + a launchd-activated loader (Apple keeps kextd/kernelmanagerd; the win is event-driven, not zero daemons). Umbrella over #67 (settle window), #176 (busyState), and #168 (EVFILT_MACHPORT / fold into configd). Phased roadmap from a 3-agent scope of Apple XNU/IOKit + kext_tools, the NextBSD hwregd/configd/launchd/mach.ko tree, and FreeBSD kqueue internals.
• NextBSD graphics — virtual-GPU DRM kexts, an end-to-end CI test, and the NVIDIA/VirtualBox tracks Porting plan The drm-kmod → Intel/AMD/Radeon kexts autoload via the in-kernel matcher, but that path is untested end-to-end — qemu emulates no real GPU. Port a virtual-GPU DRM driver (bochs first — it binds qemu’s default -vga std as a raw IOPCIPrimaryMatch node) to unlock KMS-in-VMs and the first true match→autoload→bind CI test. Scopes bochs/vboxvideo/virtio-gpu/vmwgfx, the shared blocker (drm-kmod’s missing drm_gem_vram/shmem helpers → a drm_extra_helpers.ko), the repo split (unmodified drm-kmod fork + a nextbsd-graphics kext factory + a recipe-only NVIDIA-legacy repo), and a phased roadmap. From a 7-agent scope.
• In-kernel IOKit for NextBSD — feasibility & the matching-location decision Decision doc The single fork under the kextd milestone: does driver–device matching live in the kernel (Apple-faithful — the kernel decides, kextd just loads) or in userland (faster, but a divergence)? Deep 2-agent review of FreeBSD newbus internals + Apple’s XNU IOKit / IOCatalogue / kextd, with per-option effort & risk and the “do I edit the kernel to add device IDs?” clarification (no — IDs live in kext personalities). Companion to the hwregd convergence plan; for joint review before any kextd code.
• Native EVFILT_MACHPORT migration & pipe-bridge removal — #168 plan Plan ready Move all Mach-event delivery onto the kernel’s native EVFILT_MACHPORT filter (slot -16) and delete the module-era pipe-bridge (task #39 Path B: register_event_bell + self-pipe + EVFILT_READ) — the workaround from when a .ko couldn’t add a kqueue filter slot, now obsolete since patches/0003 reserves the slot. Synthesized from a 7-agent survey of nextbsd-kernel + nextbsd + freebsd-src. Root-causes the PR #250 boot panic (a use-after-free on the port set in filt_machportattach — drops the pset lock with no reference, then knlist_add touches freed/reallocated memory at 0x70 under concurrent move_member, amplified by uninitialized worker-thread Mach state, #148) and gives the exact kernel fix. Fixes task #41 (unreliable DISPATCH_SOURCE_TYPE_MACH_RECV) at the root, retiring the pthread+mach_msg polling loops in sc_link_watch/IOKitNotify/SCNotify. 6-stage PR-gated rollout + a new concurrency stress test that reproduces the panic.
• mDNS Network browse over Mach — the empty Network-list fix Plan ready A concrete consumer of the EVFILT_MACHPORT doctrine above. The Workspace File Viewer’s Network sidebar is empty on NextBSD: mDNSResponder advertises its own .local name (peers see ThinkPad-T460s) but the dns_sd client protocol was never finished over Mach — mach_bridge.c only claims com.apple.mDNSResponder and discards the receive right, and libdns_sd ships as the AF_UNIX stub bound to a /var/run/mDNSResponder socket the nobody daemon can never create. Fix (Mach, not sockets): a dns_sd.defs MIG IDL + real Mach server wired through EVFILT_MACHPORT, plus a Mach client transport in libdns_sd. File Viewer and NetworkBrowser.app share the same NSNetServiceBrowser backend, so the UI needs zero changes. Primary repo: nextbsd-redux/nextbsd (src/mDNSResponder/); Sharing-pane launchd shim is a separate follow-on in gershwin-desktop/gershwin-components. Filed under Launchd → Mach.
• mach.ko → kernel built-in (options COMPAT_MACH) Scoping Compile the out-of-tree Mach module into the NEXTBSD kernel instead of loading it as a .ko — the answer to “how do we load mach.ko once loader.conf is gone?” and the foundational step of #180 (eliminate loader.conf). Mostly build-system wiring: the MIG server stubs are pre-committed (no codegen in the kernel build) and the syscalls already register via a SYSINIT/kern_syscall_register (no syscalls.master regen). Source migrates nextbsd/src/mach_kmod → nextbsd-kernel sys/compat/mach/, wired by a small sys/conf/{options,files} patch; the fork is never touched. Gated by the boot smoke test.
• Prove kexts work — minimal kextload + converter + PR CI Scoping Walking-skeleton proof that a FreeBSD .ko wrapped as a .kext loads via an Apple-shaped tool, gated by CI. Cheap because nextbsd already ships CFBundle (opens the bundle + Info.plist) and libIOKit — so the proof needs no OSKext: a minimal kextload/kextstat/kextunload trio over kld (Phase 1, in nextbsd) + a converter and PR CI that kextloads one leaf module in a booted VM (Phase 2, in nextbsd-kernel-modules). The full kext_tools/OSKext port is deferred but ticketed so it isn’t lost. Approach (a) chosen. Proven & merged
• Faithful kext_tools / OSKext port Plan (#182) Port Apple’s real OSKext engine (bundle discovery, dependency-graph resolution, validation, personalities) onto NextBSD with a kld backend — the faithful follow-on to the PoC, gating bulk conversion (#179) and kextd (#177). Code-grounded scope: OSKext.c ≈ 21k LOC but ~75% ports unchanged (CFBundle parsing, dep-graph math, validation); only ~25% re-backs from XNU (kext_request→kldload, IOCatalogueSendData→hwregd, KXLD/mkext deleted). Pre-SIP base avoids codesign/kernelcache. Multi-week, phased; Phase 1 (dependency resolution) is the first shippable milestone.
• kld → kext: naming + categorization Plan (#179) Groundwork for the bulk .ko→.kext conversion: a complete catalog of all 474 FreeBSD kernel modules in the tree — what each is, its category (driver / filesystem / network / crypto / KPI / …), and a proposed Apple-style org.nextbsd.* bundle id + .kext name. Built from a read-only review of freebsd-src/sys/modules by parallel agents. Surfaces the open decisions before #179: naming style, kext-vs-built-into-kernel split, sub-component/firmware handling, exclusions.
  • Raw module catalog — all 474 modules The unedited, first-pass per-module table behind the naming plan: one row per sys/modules/ entry — ko name, dir, category, purpose, proposed bundle id + .kext name, notes. Kept verbatim as the groundwork record the polished plan was distilled from.