NextBSD Research

NextBSD

• NextBSD & Gershwin — uniquely name the base libdispatch fork Research / decision Why the Gershwin global menu stopped following app-switches on NextBSD, and how it grew two builds of libdispatch. Root cause: NextBSD’s Mach-enabled libdispatch compiles EV_UDATA_SPECIFIC as 0x0100, which on FreeBSD kqueue collides with EV_FORCEONESHOT — so the menu’s file-descriptor watch fired once and was never re-armed (and the “second login fixes it” clue was a red herring: a stale active-window value left on the never-restarted login X display). Settled by on-hardware testing: the base can’t move to Gershwin’s stock build (six components need Mach sources and won’t link), and Gershwin can’t move to the Mach build — the menu still fails even with the event.c/event_kevent.c kqueue patches. So both builds must exist; the only real bug is that they share the name libdispatch.so. From a multi-agent audit across nextbsd-userland, gershwin-developer, and gershwin-components: the fix is a single rename — give the base NextBSD fork the unique soname libsystem_dispatch.so (a build-harness change; the fork is permanently owned and never synced with Apple again) and relink the base consumers onto it, while Gershwin’s stock Apple libdispatch.so is never touched. Distinct names also kill the original launchctl/dbus/sshd “Undefined symbol” poisoning. Safety rule: no single process loads both, guarded by a CI DT_NEEDED check — safe because the only base lib Gershwin consumes, libdns_sd, is a dispatch-free AF_UNIX stub. Includes a plain-language “how to read the per-library disposition” guide, the full disposition table, mDNS reconciliation, risks, and open questions. Companion to the fork-necessity review below.
• Is the NextBSD Mach libdispatch fork still needed? Research / review The prerequisite question behind the rename decision above: can NextBSD just drop its Mach libdispatch fork and use Gershwin’s stock build everywhere? No — six production components (libxpc, launchd, notifyd, and friends) depend on libdispatch’s Mach sources (DISPATCH_SOURCE_TYPE_MACH_RECV / dispatch_mach_t), and a stock HAVE_MACH=0 build can’t even compile or link them; swapping would break boot and all XPC IPC. But the instinct is half-right: the “fork” is barely a fork — a handful of compile-time deltas over stock — which is exactly why it can safely coexist with Gershwin’s stock copy once it carries a distinct soname. Component-by-component review of what actually needs Mach and why the fork earns its keep.
• NextBSD quiet console — kernel/IOKit spew off ttyv0, and an optional boot splash Plan / mockups Make the login console behave like macOS: no kernel / IOKit / driver text on ttyv0 on a normal boot (or on USB-eject), but full output under boot -v, everything still in dmesg+syslog, and panics always visible. The surprise: FreeBSD already does all the hard parts — every kernel printf splits into an always-captured TOLOG sink and a cn_mute-gated TOCONS sink, panic() force-unmutes, and RB_MUTE/RB_MUTEMSGS self-cancel under RB_VERBOSE. So the base case is a one-line loader change (boot_mute="YES" in the nextbsd-overlays fragment); the only real work is making CI boot verbose so the boot-test still sees its markers. Closes with a feasibility read on an Apple-style boot splash and four to-scale mockups (grey/black × static/spinner, real nextbsd.org cube + a CSS 12-spoke throbber) — framed as a layer on top of #272 (seamless vt(4)→drm-fbdev deferred takeover), since a splash shipped before #272 would flash to black when the GPU driver attaches. Ticket nextbsd#363.
• NextBSD path-domain conformance — adopt the gershwin four-domain layout Plan / audit Bounded follow-up to the layout spike (that decision tabled): conform NextBSD's paths to gershwin's four domains — every bare Apple /Library/X becomes /Local/Library/X; /System/Library stays. Org-wide audit of all 9 nextbsd-redux repos: six clean, freebsd-src out of scope by rule, and the rename surface confined to the Darwin userland source — ~12 runtime-behavioral sites across 6 subsystems (launchd PID-1 scan, SCPreferences, CoreFoundation, kext_tools, ASL). Headline finding: that source is duplicated byte-for-byte across nextbsd-userland/src (CI cross-build) and nextbsd/src (the ISO builder, which compiles its own copy), so the change is doubled and must land in lockstep. Includes the two hardcoded strlen traps (20→26, 14), the judgment calls (StartupItems/Logs/Spotlight), and the full file:line surface. Planning only.
• NextBSD system path layout — the Gershwin layout vs a POSIX layout Research / spike Gershwin ships an official named tools-make FilesystemLayout (--with-layout=gershwin) that roots the desktop at /System — and it collides with NextBSD on two exact directories: /System/Library/Libraries (Gershwin's ObjC install target vs NextBSD's rtld Lever-B search path) and /System/Library/LaunchDaemons (Gershwin's session plists interleave with NextBSD's 11 boot daemons). Gershwin's own make uninstall already refuses rm -rf /System on NextBSD. So: keep the domains and move Gershwin off /System (a Gershwin-layout fork — not NextBSD's call), or move NextBSD to POSIX paths (/etc/launchd.d, /usr/local/etc/launchd.d, /boot/kernel/extensions, /var/db) so rm -rf /System removes only the desktop? From a 3-agent source sweep + on-target verification: full per-path inventory, both layouts side-by-side, honest cost accounting, and the exact file:line change surface. Key findings: no /System/Library/Frameworks on the NextBSD side (libs in /usr/lib/system — no dyld/ABI knot), the kernel is filesystem-blind for kexts (zero kernel changes), and the kext cache self-disables on the move. Planning only.
• 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.