-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathlaunchd-research.html
More file actions
223 lines (218 loc) · 33.4 KB
/
Copy pathlaunchd-research.html
File metadata and controls
223 lines (218 loc) · 33.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">
<title>Launchd Research · Joe Maloney</title>
<style>
body {
font-family: -apple-system, "Helvetica Neue", Helvetica, Arial, sans-serif;
max-width: 760px;
margin: 40px auto;
padding: 0 20px;
color: #222;
line-height: 1.6;
}
header {
border-bottom: 1px solid #ccc;
padding-bottom: 16px;
margin-bottom: 24px;
}
h1 { font-size: 1.8em; margin: 0 0 4px; }
header p { margin: 0; color: #666; }
h2 {
font-size: 1.25em;
margin-top: 2em;
border-bottom: 1px solid #eee;
padding-bottom: 4px;
}
ul { padding-left: 20px; }
li { margin-bottom: 8px; }
a { color: #0366d6; text-decoration: none; }
a:hover { text-decoration: underline; }
.guides li { margin-bottom: 12px; }
.guides .desc { color: #666; font-size: 0.92em; display: block; }
footer {
margin-top: 3em;
padding-top: 16px;
border-top: 1px solid #eee;
color: #888;
font-size: 0.9em;
}
</style>
</head>
<body>
<header>
<h1>Launchd Research</h1>
<p><a href="index.html">← Back to home</a> · <a href="https://github.com/pkgdemon">github.com/pkgdemon</a></p>
</header>
<h2>Launchd Research Sockets</h2>
<ul class="guides">
<li>
<a href="gershwin-livecd-launchd-plan.html?v=20260514e">gershwin-on-freebsd: livecd rework + launchd port — plan <span class="pill ok">Phase 1 + 2 CI-green</span></a>
<span class="desc">Sequenced integration of freebsd-launchd's work into <a href="https://github.com/pkgdemon/gershwin-on-freebsd">pkgdemon/gershwin-on-freebsd</a>. Phase 1 landed (single-root unionfs + init_chroot pivot, CI boot-test gate, feat/libs-corebase). Phase 2 landed (launchd as PID 1 via Option D, bedrock plists from freebsd-launchd, gershwin-specific dshelper/loginwindow/gdomap plists, dhcpcd swap, no getty — LoginWindow is the login). Phase 3 polish (dbus, kmodloader, gdomap lo0 fix, dshelper daemonization, ASL, single-user) deferred.</span>
</li>
<li>
<a href="freebsd-launchd-plan.html?v=20260514">FreeBSD launchd — porting plan (AF_UNIX sockets track) <span class="pill info">Superseded</span></a>
<span class="desc">Original non-Mach port of Apple's launchd — AF_UNIX/sockets only, GNUstep system-domain libs + launchd built inside a livecd staging chroot, boot-tested in qemu. <strong>Superseded by <a href="freebsd-launchd-mach-plan.html">freebsd-launchd-mach (v2)</a></strong>, which is now working end-to-end on stock FreeBSD-15 (mach.ko + libmach + userland <code>mach_msg</code>, 19/19 smoke green). Kept for historical context and as the lineage of the gershwin-livecd integration; the child plans below were drafted against this track and inherit its superseded status.</span>
<ul>
<li>
<a href="freebsd-launchd-service-ordering.html?v=20260514">FreeBSD launchd — service ordering <span class="pill info">Superseded</span></a>
<span class="desc">Cross-service ordering on freebsd-launchd: what makes <code>varrun → cron</code>, <code>syslogd</code>-first, and <code>dhcpcd</code>-after-<code>kmodloader</code> work declaratively rather than by alphabetical-filename luck. netconfigd is one downstream consumer of the same primitives; the doc walks both layers. Superseded along with the sockets track.</span>
</li>
<li>
<a href="freebsd-kmodloader-plan.html?v=20260514">FreeBSD kmodloader — porting plan <span class="pill info">Superseded</span></a>
<span class="desc">Apple-shaped clean-room daemon: every hardware-class kmod autoloads at boot or hot-plug. Closes the gap where stock FreeBSD doesn't aggressively bind GPU/NIC/USB drivers without manual <code>kld_list=</code> editing. <strong>Superseded in the mach track by <a href="freebsd-hardware-registry-iokit-plan.html">hwregd</a></strong>, which lifts devmatch's <code>search_hints()</code> parser into a daemon that reads <code>/dev/devctl</code> directly and kldload's on <code>?nomatch</code> — same job, integrated with the Mach IORegistry instead of standing alone.</span>
<ul>
<li>
<a href="freebsd-gpu-detection-comparison.html?v=20260514">GPU autodetection comparison — kmodloader vs. GhostBSD xconfig vs. NomadBSD initgfx vs. xlibre vs. Linux</a>
<span class="desc">Side-by-side comparison of how each system maps GPUs to drivers, handles fallback to scfb/vesa/efifb, and what happens when a DRM kmod loads but the chip is too new to bind. Cites source line:column for the key logic in each.</span>
</li>
</ul>
</li>
</ul>
</li>
<li>
<a href="freebsd-mach-kmod-plan.html?v=20260514">FreeBSD <code>mach.ko</code> — out-of-tree kernel module feasibility (v1) <span class="pill info">Superseded</span></a>
<span class="desc">Predecessor investigation that led to <a href="freebsd-launchd-mach-plan.html">freebsd-launchd-mach (v2)</a>. Earlier framing: build a minimal <code>mach.ko</code> from scratch covering the ~15-call subset configd and launchd's bootstrap actually use. Stable-KPI-only diet so the artifact rebuilds only at major FreeBSD bumps. Shipped from <code>freebsd-launchd</code>'s CI as a per-major release tarball alongside the live ISO. <strong>Superseded by v2</strong> once direct inspection of NextBSD and ravynOS revealed a working module already exists, but kept for the API-surface analysis (the configd Mach-surface inventory in §8 and the stable-KPI / KBI diet in §5 are cited in-body from v2).</span>
</li>
</ul>
<h2>Launchd Research Mach</h2>
<ul class="guides">
<li>
<a href="freebsd-launchd-mach-plan.html?v=20260514">freebsd-launchd-mach — pure-port track forking ravynOS's Mach + launchd stack (v2) <span class="pill ok">Phase B Tier 1 + C1-C3 complete</span></a>
<span class="desc">FreeBSD modernization plan. Two-repo strategy: keep <code>freebsd-launchd</code> on the AF_UNIX track unchanged; create a new <code>freebsd-launchd-mach</code> repo that extracts ravynOS's <code>sys/compat/mach/</code> as an out-of-tree <code>mach.ko</code>, lifts their launchd / liblaunch / libxpc / libdispatch, integrates the configd Apple source already imported by <code>freebsd-launchd</code>, and reuses the existing CI / ISO scaffolding. Apple source covers only the system-services layer (Mach, launchd, configd, notifyd, asl, dispatch, xpc); GNUstep stays for the framework layer (Foundation, AppKit, libobjc2). Stays ELF; no dyld, no Mach-O execution, Linux compat unaffected. <strong>Status:</strong> mach.ko builds + kldloads on stock FreeBSD-15; 4 wired trap-family syscalls + libmach + lazy Mach init + end-to-end userland <code>mach_msg</code> proof; 19/19 smoke green, zero kernel patches.</span>
<ul>
<li>
<a href="freebsd-launchctl-corefoundation-spike.html?v=20260514">launchctl CoreFoundation spike — picking the CF source for launchd-842</a>
<span class="desc">Picks the CoreFoundation source for the launchd-842 launchctl port. Apple's <code>launchctl.c</code> is 4,549 LOC of CF-heavy code. Audits three candidates — gnustep/libs-base, gnustep/libs-corebase, swiftlang/swift-corelibs-foundation — against the exact symbol set <code>launchctl.c</code> uses, with a buy/build/skip decision per candidate. Settles the CF choice that the v2 plan's lede references.</span>
</li>
<li>
<a href="freebsd-libcorefoundation-icu-audit.html?v=20260514">libCoreFoundation ICU audit — do we need ICU on the ISO?</a>
<span class="desc">Decision-quality survey of ICU usage across 22 Apple-source components relevant to the launchd-adjacent system-services stack. Reverses the CF spike's §14.4 "install ICU as a build dep, keep all CF source files" call: <strong>no ICU on the ISO</strong>, with the caveat that two daemons (configd, IPConfiguration) and one library (PowerManagement) touch CF-ICU APIs in narrow cosmetic / debug paths that have direct libc-equivalent replacements. <strong>Superseded by the libicu port plan</strong> — CI execution surfaced 33 additional ICU call sites in CF the audit missed, forcing the decision to flip from Option A (drop) to Option C (vendor).</span>
</li>
<li>
<a href="freebsd-libicu-port-plan.html?v=20260515">libicu port plan — vendoring Apple ICU into freebsd-launchd-mach</a>
<span class="desc">Concrete, agent-derived plan after the audit's Option A turned out to miss 33 ICU call sites (CFString grapheme detection, CFTimeZone localized names, CFBundle_Locale + the Apple-only <code>ualoc_localizationsToUse</code>). Mid-plan vendor-source pivot: started with apple-oss-distributions/ICU, found that swift-corelibs CF actually expects <code>apple/swift-foundation-icu</code> (purpose-built, native <code>_foundation_unicode/</code> namespace, Apache 2.0). Final shape: vendor swift-foundation-icu at <code>src/swift-foundation-icu/</code>, build via CMake to <code>/usr/lib/system/libicucore.so</code> (~40–50 MB installed, matching macOS's libicucore.dylib).</span>
</li>
<li>
<a href="freebsd-launchd-842-porting-plan.html?v=20260514">freebsd-launchd-842 — porting Apple's last open-source launchd <span class="pill pill-warn">Plan drafted</span></a>
<span class="desc">Data-grounded porting plan for Apple's <code>launchd-842.92.1</code> (2014, ~28.5k LOC, last open source pre-libxpc-split) onto our <code>mach.ko</code> + <code>libsystem_kernel</code> + <code>libdispatch</code> + <code>libxpc</code> + <code>bootstrap_server</code> stack. Drafted from four parallel research passes through the verbatim Apple source: build-system map (7 MIG .defs files), Mach/IPC gap analysis (audit-trailer materialization + dead-name notifications + port sets are the hard items), PID-1 vs daemon-mode split (single <code>pid1_magic</code> gate; per-user mode is the natural non-PID-1 analogue), and launchctl + control protocol (25 subcommands, <code>launch_msg</code> over Unix socket, CFPropertyList plist parsing). Phases I1 (build + exec only, <code>LAUNCHD-BUILD-OK</code>), I2 (core functionality with multiple test daemons: KeepAlive, StartInterval, WatchPaths, Sockets), then explicit user checkpoint before any PID 1 work.</span>
</li>
<li>
<a href="freebsd-libxpc-plan.html?v=20260514">freebsd-libxpc — porting Apple XPC onto our mach.ko</a>
<span class="desc">Phased porting plan for libxpc on FreeBSD. Phase 0 starts with a libdispatch Mach backend (new <code>event_mach_freebsd.c</code> shipped as a patch to gershwin-developer); subsequent phases fork libxpc from ravynOS's tree, add a bootstrap server, swap freebsd-launchd's daemon for a clean Apple <code>launchd-842.92.1</code> import, build a hybrid CoreFoundation library, and finally bring up configd. Audits related daemons (asl, notifyd, mDNSResponder, IPConfiguration, DiskArbitration). NSXPCConnection documented as a downstream GNUstep contribution.</span>
<ul>
<li>
<a href="freebsd-libxpc-foundation-spike.html?v=20260514">Foundation / CoreFoundation spike for freebsd-libxpc</a>
<span class="desc">Companion spike: which Foundation and CoreFoundation implementations do downstream daemon ports actually need? Compares GNUstep <code>libs-corebase</code>, Apple CF-Lite-1153.18 (2015), and swift-corelibs-foundation's CoreFoundation. Per-port symbol audit: configd (12,968 CF calls, 42 CFMachPort sites), SystemConfiguration framework (6,925 CF, 0 NS), asl/notifyd/libnotify (zero CF). Recommends hybrid: GNUstep value-type CF + a supplementary <code>libCFRuntime.so</code> sourced from swift-corelibs CF for the runtime parts (CFMachPort, CFRunLoop v1, CFPreferences, CFBundle plugin loader). libgnustep-base for Foundation; no swift-corelibs Foundation.</span>
</li>
<li>
<a href="freebsd-libxpc-libdispatch-mach-spike.html?v=20260514">libdispatch Mach backend spike for freebsd-libxpc</a>
<span class="desc">Why we need to patch libdispatch on FreeBSD: empirical grep shows 5+ components use <code>DISPATCH_SOURCE_TYPE_MACH_RECV</code> (libxpc, libnotify, notifyd, notifyutil, SystemConfiguration framework). Three options analyzed: patch libdispatch once, polling threads per consumer, or a small bridge library. Recommends Option 1. Includes the comprehensive "all in-scope apps" dispatch-dep matrix, the existing gershwin kqueue performance patches we inherit, install-path comparison (<code>/System/Library/Libraries</code> vs <code>/usr/lib</code> vs <code>/usr/local/lib</code>), Block.h coordination with FreeBSD pkgbase.</span>
</li>
<li>
<a href="freebsd-libxpc-install-layout-spike.html?v=20260514">Install layout spike — per-component paths across four layouts</a>
<span class="desc">Per-component install-path matrix for every component we port: <code>mach.ko</code>, libmach, libdispatch, libxpc, liblaunch, launchd (+launchctl), asl family (syslogd + aslmanager + libasl + syslog), notifyd (+libnotify + notifyutil), configd (+scutil + SystemConfiguration framework + plugins), CoreFoundation hybrid, mDNSResponder, IPConfiguration (+ipconfig + bootpd + helpers), DiskArbitration (framework + daemon + agent), Block.h, GNUstep stack. Four columns: Apple macOS / <code>/usr/lib/system/</code> (Apple-like) / Gershwin <code>/System/Library/</code> / FreeBSD base <code>/usr/lib</code>. Documents project policies: <code>/Local/Library</code> never <code>/Library</code>; GNUstep core always at <code>/System/Library/</code>; <code>/System/Applications/</code> for system .app bundles; gershwin conditional-skip pattern; <code>/System/Library/Tools/</code> as daemon alternative on every binary.</span>
</li>
</ul>
</li>
<li>
<a href="freebsd-mach-kmod-syscall-slots-spike.html?v=20260514">mach.ko syscall slot expansion — audit plan <span class="pill pill-warn">In review</span></a>
<span class="desc">freebsd-launchd-mach has wired 10 Mach syscalls into FreeBSD’s reserved <code>lkmnosys</code> slot range (210–219); adding an 11th fails with <code>ENFILE</code>. Forward-demand estimate puts total Mach syscalls at 30–40 by the time launchd+configd+notifyd+asl are ported. This is an <strong>audit plan</strong>, not a design decision: outlines why the 10-slot limit exists, what Apple does differently (separate <code>mach_trap_table</code> with negative syscall numbers), the risk profile of each expansion path (RESERVED-slot claiming, multiplexer dispatcher, base-kernel patch), and the four sub-agent audits to run before picking a path.</span>
</li>
<li>
<a href="freebsd-apple-userland-cmds-plan.html?v=20260526">freebsd-apple-userland-cmds — porting Apple userland onto FreeBSD <span class="pill info">v3 rule-flip</span></a>
<span class="desc">Data-grounded audit of nine Apple userland repos (bootstrap_cmds, file_cmds, shell_cmds, system_cmds, network_cmds, text_cmds, adv_cmds, PowerManagement, DiskArbitration). <strong>v3 (2026-05-26)</strong>: retired the per-binary "port if Apple has integration advantage, skip otherwise" rule; new rule is "vendor every Apple userland repo we have open-source for, port all binaries, modify as needed." ~155 binaries in scope. Items requiring Apple-closed-source or Apple-OSS-archive fetch split off to dedicated scoping plans: hdiutil/hdik (closed; see hdiutil port plan), diskdev_cmds (mount/fsck/newfs; needs Apple OSS fetch + UFS2 forward-port), kext loader (needs XNU OSKext ported into mach.ko). Transitional <code>/usr/src</code> manifest contracts from ~40 entries to ~13 FreeBSD-kernel-tied tools (kld*, mdconfig, geom, devfs-rules, dumpon/savecore, swapon).</span>
<ul>
<li>
<a href="freebsd-srclist-build-plan.html?v=20260526">srclist build strategy — which /usr/src tools build standalone <span class="pill info">investigation</span></a>
<span class="desc">Deep-dive investigation triggered by CI failure on PR #107 (build /rescue/ from /usr/src). Six parallel research-agent passes settled: (1) per-tool dep categorization (47/48 sampled tools build standalone), (2) complete pkg inventory (FreeBSD-runtime 187 bin / 96 dirs; utilities 604/330; rescue 148/0 new), (3) FreeBSD build infrastructure (full buildworld 45-90min cold; per-subdir make ~30s; leaf-only is right shape for ~15min CI), (4) drop-or-keep prereq matrix (only /sbin/ifconfig + rescue's ifconfig+ipf force generated-header libs), (5) deep per-srcdir scoping of FreeBSD-runtime (47 KEEP from 96), (6) deep per-srcdir scoping of FreeBSD-utilities (63 KEEP from ~330). <strong>Key reframing:</strong> Apple has no /rescue/ at all; ticket #104 framing was wrong — drop without replacing. Issue #104 + PR #107 closed 2026-05-26. <strong>For #105:</strong> runtime + utilities are separate pkgs, scoped separately; combined first-iter manifest = <strong>110 entries (down from ~425 = 74% trim)</strong>, ~18-19 min CI serial; no buildworld needed. Both ready-to-paste manifests in §9.2 + §10.3.</span>
</li>
<li>
<a href="freebsd-hdiutil-port-plan.html?v=20260526">hdiutil / hdik port plan — four options for review <span class="pill pill-warn">decision pending</span></a>
<span class="desc">Decision document for <code>hdiutil</code>/<code>hdik</code>/DiskImages on freebsd-launchd-mach. Spun out of userland-cmds v3 §16 deferred scoping after research into Darling's reimplementation revealed it covers ~7% of Apple's surface (attach + detach only, read-only, UDIF-only HFS+) and is GPL-3.0. Apple's <code>hdiutil</code>/<code>hdik</code>/DiskImages.framework are closed-source — never published. Four options laid out: A) clean-room MIT fresh-write in <code>src/hdiutil/</code> matching Apple's documented ~30-subcommand surface, phased; B) vendor darling-dmg as-is (GPL-3.0, ~7% coverage, 1-2 weeks); C) vendor darling-dmg + extend (GPL-3.0 inherited by extensions); D) defer indefinitely (current v3 plan position). Decision matrix + cross-cutting concerns (GPLv3 vs Apple's no-GPLv3 posture, <code>libdmg.so</code> linking constraint, APFS path, <code>md(4)</code> binding) + phased scope if A or C selected. No decision made in the document — for review.</span>
</li>
</ul>
</li>
<li>
<a href="freebsd-hardware-registry-iokit-plan.html?v=20260516c">freebsd hardware registry + IOKit userland — porting plan <span class="pill pill-warn">Draft</span></a>
<span class="desc">FreeBSD-devd + FreeBSD-devmatch were removed at commit <code>88694f0</code>, leaving no kldload-on-nomatch and no notification mechanism for hardware events. This plan builds <code>hwregd</code> as a registry-first cohesive block: <strong>Phase 0</strong> (~3-4 wk) lifts devmatch's <code>search_hints()</code> parser into a daemon that reads <code>/dev/devctl</code> directly, kldload's on <code>?nomatch</code>, and emits Mach events. <strong>Phase 1</strong> (~5-6 wk) grows it into a full IORegistry + IOKit-shape Mach-RPC API. Then <code>HardwareMatch</code> launchd plist key (~1.5 wk) + IOKitUser facade K1+K2 (~6 wk). At step 4 devd+devmatch are fully replaced and <code>ioreg -l</code> works — <strong>this is the foundation block, ~4 months</strong>. Then a demand-driven decision point: configd+IPConfiguration (~7 wk, network mgmt) vs. powerd+IOKitUser K3 (~4 wk, power mgmt) vs. cuse-backed DriverKit-shape framework (~4-8 mo, native userspace drivers). Verdicts on related paths: kernel kext support <strong>skip</strong> (3-5 yr ABI emulation diversion); Apple DriverKit binary compat <strong>defer</strong> (8-18 mo).</span>
</li>
<li>
<a href="freebsd-configd-plan.html?v=20260514">FreeBSD configd — porting plan</a>
<span class="desc">Companion to launchd. Ports Apple's configd as <code>netconfigd</code>: one daemon owns network state, hostname, DNS. Drops Mach IPC for GNUstep Distributed Objects; libdispatch for kernel events.</span>
<ul>
<li>
<a href="freebsd-ipconfiguration-plan.html?v=20260514">FreeBSD IPConfiguration — porting plan</a>
<span class="desc">Eventual replacement for dhcpcd. Ports Apple's IPConfiguration as a netconfigd plugin (DHCPv4 + DHCPv6 + IPv4LL + RA, ~57k LOC, 6-9 person-months). Currently <strong>deferred</strong> — dhcpcd works, the cost-benefit doesn't justify the port until netconfigd Phase 2-3 ships and a real reason surfaces.</span>
<ul>
<li>
<a href="freebsd-wifi-management.html?v=20260514">FreeBSD WiFi management — Apple stack research</a>
<span class="desc">What macOS uses for WiFi (it's not <code>wpa_supplicant</code>): <code>wifid</code> + <code>Apple80211</code> + <code>CoreWLAN</code>, mostly closed source. Only the <code>eap8021x</code> EAP/802.1X code is open. We ship <code>wpa_supplicant</code> from ports; sketches a hypothetical <code>wifid-fbsd</code> wrapper if Apple-shape API symmetry ever matters. Includes a <code>wifid</code>-responsibility map (<code>wpa_supplicant</code> vs <code>iwd</code>) and a glossary (AWDL, Continuity, AirDrop, SAE, OWE, 802.11r/k/v, net80211 vs nl80211).</span>
</li>
<li>
<a href="freebsd-bluetooth-management.html?v=20260615">FreeBSD Bluetooth management — Apple stack research</a>
<span class="desc">How macOS Bluetooth works (a teardown of the fully closed <code>bluetoothd</code> + <code>IOBluetooth</code>/<code>CoreBluetooth</code> + <code>IOBluetoothFamily.kext</code> stack, the Classic-vs-BLE split, and the proprietary <code>MagicPairing</code>/Continuity protocols). The most closed component yet — <strong>zero</strong> Apple open source, headers only. FreeBSD's Netgraph stack (<code>ng_hci</code>/<code>hcsecd</code>/<code>sdpd</code>/<code>bthidd</code>) is Classic-only with <strong>no BLE/GATT/SMP</strong>, and BlueZ can't rescue it (GPL + Linux-kernel-coupled). Weighs extend-Netgraph vs port-BlueZ vs greenfield-userland-LE, sketches a <code>bluetoothd-fbsd</code>, and ties into the AirDrop/Continuity two-radio (BLE discovery + AWDL transfer) story.</span>
</li>
</ul>
</li>
</ul>
</li>
<li>
<a href="freebsd-asl-plan.html?v=20260514">FreeBSD ASL — porting plan</a>
<span class="desc">Apple System Logger replacing FreeBSD's <code>/usr/sbin/syslogd</code>. Structured log records (Sender/Facility/PID/Time queries without grep), binary-store + BSD-text dual output (<code>tail /var/log/messages</code> still works).</span>
</li>
<li>
<a href="freebsd-notifyd-plan.html?v=20260514">FreeBSD notifyd — porting plan</a>
<span class="desc">Apple's lightweight named-event pub/sub bus (<code>libnotify</code> + <code>notifyd</code>). Cross-process event coordination for gershwin desktop — theme changes, network state, power events — via the same C API Apple-derived apps already speak.</span>
</li>
<li>
<a href="freebsd-hostnamed-plan.html?v=20260523">FreeBSD hostnamed — porting plan <span class="pill info">v0 draft</span></a>
<span class="desc">Stops shipping <code>FreeBSD/amd64 (Amnesiac)</code> as the Bonjour name. Clean-room daemon that synthesizes a hardware-derived default at first boot (<code>ThinkPad-T420-8AB123</code>, <code>Mac-mini-F12345</code>, …) from <code>kenv</code> + SMBIOS, sets <code>kern.hostname</code>, and publishes Apple's three-name shape (<code>ComputerName</code> / <code>LocalHostName</code> / <code>HostName</code>) to configd's <code>SCDynamicStore</code> so mDNSResponder has a real <code>.local</code> name to announce. Hybrid source: vendors Apple's <code>Plugins/IPMonitor/set-hostname.c</code> (~500 LOC, APSL 2.0) for the precedence/DHCP-option-12/reverse-DNS pipeline; clean-rooms the hardware-synthesis fallback that fills Setup Assistant's role on real Macs. Standalone (not a configd plugin) because this repo's <code>configd</code> has no <code>.bundle</code> loader yet — same trade <code>hwregd</code> / <code>ipconfigd</code> / <code>diskarbitrationd</code> already took.</span>
</li>
<li>
<a href="freebsd-keychain-port-plan.html?v=20260615">FreeBSD Keychain — porting / alternatives plan <span class="pill info">Scoping</span></a>
<span class="desc">What macOS Keychain is (a launchd-managed <code>securityd</code>/<code>secd</code> Mach daemon + <code>Security.framework</code> library + on-disk keychains + SEP), and the full option space for a NextBSD local secret store with Apple's <code>SecItem</code> API. Source is published (<code>apple-oss-distributions/Security</code> + <code>securityd</code>) but unbuildable — depends on closed <code>corecrypto</code> + SEP firmware. Seven alternatives weighed: full <code>Security.framework</code> port (rejected: closed crypto/SEP, 6–12+ mo), wrapping <code>gnome-keyring</code>/<code>libsecret</code> (fallback: drags in D-Bus + LGPL), KWallet, <code>pass</code>/gpg, PKCS#11 (key-class backend), plaintext plist (interim). <strong>Recommended:</strong> clean-room <code>com.apple.securityd</code> (keeps Apple's exact launchd label, matching the shipped <code>com.apple.configd</code>/<code>notifyd</code>) — launchd Mach/DO daemon implementing the public <code>SecItem</code> facade over an encrypted store with base <code>libcrypto</code>, optional TPM2 sealing as the SEP analog, <code>pam_secd</code> unlock-at-login tying into the PAM port. ~2–3 person-months for a usable subset. Honest threat model (software-only = gnome-keyring-grade, not SEP-grade). <strong>Not a commitment</strong> — starts when a real consumer (<code>wifid-fbsd</code> creds, mail/browser, network shares) lands; until then secrets stay inline in plaintext <code>Network.plist</code>.</span>
</li>
<li>
<a href="freebsd-pam-port-plan.html?v=20260525">FreeBSD PAM port — replacing FreeBSD-pam with Apple OpenPAM <span class="pill info">v1 ready to execute</span></a>
<span class="desc">Drops <code>FreeBSD-pam</code> + <code>FreeBSD-pam-lib</code> packages from the image, replaces with Apple OpenPAM (framework + bundled <code>pam_unix</code> / <code>pam_deny</code> / <code>pam_permit</code> from <code>apple-oss-distributions/OpenPAM/openpam/modules/</code>) plus 5 standalone Apple modules from <code>pam_modules</code> (<code>pam_self</code>, <code>pam_rootok</code>, <code>pam_uwtmp</code>, <code>pam_nologin</code>, <code>pam_env</code>). Zero new module code authored — pure Apple-source vendoring. Trigger: <code>pam_xdg</code> session failure during hostnamed iter 1 RunAtLoad scan race; goal #2 is dropping XDG entirely. Apple’s upstream <code>pam_unix.c</code> (196 LOC, Dag-Erling Smørgrav, same upstream as FreeBSD’s) defers backend selection to NSS via <code>getpwnam</code>+<code>crypt</code>, so the gershwin-side <code>nss_gershwin</code> / dshelper path is transparent — no PAM-side knowledge of any specific directory. 4 iters: vendor OpenPAM → vendor 5 standalone modules → overlay <code>/etc/pam.d/*</code> + drop FreeBSD-pam packages → restore <code>RunAtLoad=true</code> on hostnamed+syslogd. Includes detailed FreeBSD-runtime + FreeBSD-rescue breakage analysis (none, provided the overlay only references modules we ship).</span>
</li>
<li>
<a href="freebsd-opendirectory-port-plan.html?v=20260525">FreeBSD OpenDirectory port — scoping (deferred) <span class="pill info">Scoping only</span></a>
<span class="desc">Companion to the PAM port, capturing what porting Apple’s OD stack would entail before it’s a real need. Binding constraints: <code>opendirectoryd</code> daemon source is CLOSED (no XPC wire-protocol headers, only the client framework <code>apple-oss-distributions/OpenDirectory</code> is open); Active Directory plugin is CLOSED (the other DS plugins LDAPv3/NIS/PasswordServer/NSL/etc. are open in their own repos); Tiger NetInfo open-source drop is incomplete (only <code>common/</code> lib, daemons + CLIs were dropped). Inventory of what IS open (DirectoryService legacy daemon ~50k LOC C++/MIG, DSTools, Kerberos, SMBClient, samba) with realistic port-effort estimates. Three-way feature comparison: Tiger NetInfo vs Snow Leopard DirectoryService vs gershwin’s existing dshelper-based DirectoryServices. End-state analysis for OD-client (~6-8 weeks), AD-bind (~5-6 months incl. writing the closed AD plugin from scratch), OD-server-for-Macs (~2-3 months + ongoing crypto maintenance), AD-server-impersonation (not viable; that’s Samba 4’s territory). <strong>Not a commitment</strong> — revisited only when a real consumer (Kerberos SSO, AD bind, modern Macs binding to FreeBSD/Mach server, password policy needs) emerges. Until then the PAM port stands on its own; this plan is reference data.</span>
</li>
<li>
<a href="freebsd-mdnsresponder-plan.html?v=20260514">FreeBSD mDNSResponder — porting plan</a>
<span class="desc">Bonjour / zeroconf service discovery: <code>.local</code> hostnames, automatic printer / file-share discovery on the LAN. Surprise win — Apple's source already has a cross-platform <code>mDNSPosix</code> layer with zero Mach surface; the port is mostly a configuration exercise.</span>
</li>
<li>
<a href="mdns-network-browse-mach-plan.html?v=20260621">mDNS Network browse over Mach — the empty Network-list fix <span class="pill warn">Plan ready</span></a>
<span class="desc">Course-corrects the porting plan above: the Workspace File Viewer's <strong>Network</strong> list is empty on NextBSD because the <code>dns_sd</code> <em>client</em> protocol was never finished over Mach. The daemon advertises its own <code>.local</code> name (peers see it) but <code>mach_bridge.c</code> only claims the <code>com.apple.mDNSResponder</code> service and never serves it; <code>libdns_sd</code> ships as the AF_UNIX stub talking to a <code>/var/run/mDNSResponder</code> socket that never exists. Per the “Mach not sockets” doctrine: add a <code>dns_sd.defs</code> MIG IDL + real Mach server wired through <code>EVFILT_MACHPORT</code>, plus a Mach transport in <code>libdns_sd</code>. The File Viewer and NetworkBrowser.app share the same <code>NSNetServiceBrowser</code> backend, so the UI needs zero changes. From a 3-agent investigation + live probing of <code>thinkpad-t460s</code>. Primary repo: <code>nextbsd-redux/nextbsd</code>; Sharing-pane launchd shim is a separate follow-on in <code>gershwin-components</code>.</span>
</li>
<li>
<a href="freebsd-disk-arbitration-plan.html?v=20260514">FreeBSD DiskArbitration — porting plan</a>
<span class="desc">Disk attach/detach events, mount/unmount/eject coordination, mount-policy approvals. Replaces ad-hoc <code>kqueue(EVFILT_FS)</code> polling with Apple's clean event API. Workspace File Viewer's "Devices" sidebar wants this. The hard one: replaces IOKit with <code>libgeom</code> + <code>devctl(4)</code>.</span>
</li>
<li>
<a href="freebsd-hfsplus-port-plan.html?v=20260526">HFS+ kernel module port plan — vendoring Apple HFS to FreeBSD <span class="pill info">v1 draft</span></a>
<span class="desc">Port Apple's HFS+ filesystem as a vendored FreeBSD <code>hfs.ko</code> + userland tools (<code>mount_hfs</code>, <code>newfs_hfs</code>, <code>fsck_hfs</code>). Targets read-write mount + journal + decmpfs. <strong>Headline find:</strong> a GSoC 2025 port (<code>stupendoussuperpowers/freebsd_hfs</code>, FreeBSD Foundation-mentored) already exists with RO+RW mount + basic VOPs working — saves ~3 engineer-months. Strategy: fork the GSoC port (which itself vendors <code>apple-oss-distributions/hfs</code> verbatim + adds a FreeBSD VFS compat shim) rather than starting from Linux <code>hfsplus.ko</code> (GPL-2 incompatible) or fresh-writing. 6-phase delivery (RO mount → RW → fsck → journal → decmpfs → mmap), ~3-4 engineer-months total, with MVP shortcut (Phases 1+3+5 = ~6-9 weeks) for native DMG-mounting. Scopes <a href="https://github.com/pkgdemon/freebsd-launchd-mach/issues/73">issue #73</a>.</span>
<ul>
<li>
<a href="freebsd-hfsplus-bootloader-plan.html?v=20260526">HFS+ bootloader plan — boot-132 vs libsa vs UFS-for-/boot <span class="pill info">recommendation: Option C</span></a>
<span class="desc">Companion to the HFS+ kmod plan. Addresses: how does the bootloader find the kernel if <code>/boot</code> is HFS+? FreeBSD's <code>stand/loader</code> can read UFS/ZFS/ext2/cd9660/FAT/NFS but not HFS+. Three options: A) port Apple <code>boot-132</code> (last released 2006, BIOS+i386-only, APSL 2.0) or modern derivatives (OpenCore BSD-3, Clover BSD-2) — all Darwin-platform loaders that would need ~3+ person-months to gut for FreeBSD handoff; B) add HFS+ reader to <code>stand/libsa</code> (~2-3 weeks, port Clover's LGPL VBoxHfs into libsa's <code>fs_ops</code> ABI); <strong>C) UFS for <code>/boot</code>, HFS+ for data — recommended, zero work, matches FreeBSD's default install layout</strong>. HFS+ kmod handles all post-boot HFS+ access regardless. Scopes <a href="https://github.com/pkgdemon/freebsd-launchd-mach/issues/80">issue #80</a>.</span>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<footer>
<p><a href="index.html">← Back to home</a></p>
</footer>
</body>
</html>