← Back · evidence in Mach IPC — what has been eliminated

Dropping libxpc and libdispatch

Can NextBSD ship pre-XPC, open-source Apple components instead of maintaining reimplementations? Scoping, with the parts that are measured separated from the parts that are not.

Drafted 2026-09-01, after the Mach IPC wedge was fixed. The component survey has not been run yet — Phase 0 below.

1. Why this is on the table

Two boot-path failures were diagnosed today, and neither was a Mach defect:

The wedge that started the whole investigation was not libxpc — it was EV_CLEAR on a kqueue readiness knote in libmach. That matters: the case for this effort rests on the two boot-path failures above, not on the wedge.

2. What is actually a reimplementation

2b. Correction: libmach has an upstream — it is just not called libmach

Verified (survey, 2026-09-01): a search of apple-oss-distributions returns zero repositories named libmach. There is no Apple project by that name and never was; the name descends from CMU Mach 3.0 and NeXTSTEP. But the Mach userland is open source and always has been — it lives in xnu/libsyscall/mach (67 files, built into libsystem_kernel.dylib) with its header vocabulary in xnu/osfmk/mach.

Licensing is a non-issue: mach_error_string.c and mig_reply_setup.c carry dual APSL 2.0 + Carnegie Mellon Mach headers, the three .defs already vendored into src/libmach carry APSL 2.0, and NOTICE.md already records libmach → libsystem_kernel, APSL-2.0 alongside bootstrap_cmds, configd, libIOKit, kext_tools, Libnotify and syslog. Adopting from libsyscall introduces no new licence family.

The “43 files” figure was misleading

An earlier survey reported libmach as 40-of-43 files NextBSD-original. Arithmetically true, materially misleading: those 43 files are 2 .c files (2,636 lines), 3 already-vendored Apple .defs, 37 headers, a Makefile and a .pc. The hand-maintained code is concentrated in two files, and the header bulk — the larger part of the count — has an Apple upstream the survey missed.

What Apple gives away that we hand-stubbed

The standout is the error-table family. include/mach/mach_error.h currently ships this:

static __inline const char *
mach_error_string(mach_error_t error_value)
{
	(void)error_value;
	return "(mach error — see <mach/kern_return.h> for the code)";
}

mach_error_type() likewise returns "(unknown)", and the header admits it: “We don’t ship those tables… replace the inline with a real table-driven implementation.” Apple ships exactly that table — roughly 50 KB across mach_error_string.c, mach_error.c, error_codes.c, errorlib.h and eight .sub tables (err_ipc, err_mach_ipc, err_kern, err_vm, err_server, err_us, err_iokit, err_libkern). mach_error_string.c references only _mach_errors and err_max_system — zero port, task or syscall dependency, so it is a pure vendor-and-link with no exposure to the port-name divergence below. It upgrades every mach_error_string() call site in libbootstrap and launchd from a constant string to real diagnostics.

Four smaller items are the same shape — Apple has them, we either hand-wrote or stubbed them, and none touch port representation: mig_reply_setup.c (six lines of field copying; not implemented here at all), mig_strncpy.c (hand-written at mach_traps.c:937), and port_descriptions.c / slot_name.c (right-type→string, nothing here). One larger: mach_msg_server_once, whose in-tree version returns MACH_RCV_TIMED_OUT unconditionally with the comment “for Phase I1c we don’t run the helper-downcall path.” Apple’s real one is in mach_msg.c.

The one header that must never be vendored

Port names are file descriptors here, and include/mach/port.h inverts Apple’s bit layout deliberately:

#define MACH_PORT_INDEX_MASK	0x00ffffffU
#define MACH_PORT_INDEX(name)	((mach_port_name_t)(name) & MACH_PORT_INDEX_MASK)
#define MACH_PORT_GEN(name)	((mach_port_name_t)(name) & 0xff000000U)

The generation goes in the high byte and the index in the low 24 bits, “because a port name is currently also a file descriptor and the index half has to stay a valid fd number.” Apple’s layout is the opposite. Taking Apple’s port.h would not fail to compile — it would silently corrupt hashing, exactly the way the previously-wrong macro made MACH_PORT_INDEX return zero for every port and collapsed launchd’s HASH_PORT and libdispatch’s VL_HASH to linear scans. port_obj.c and mach_right.c inherit the same assumption and are equally unportable, as is mach_traps.s (XNU trap numbers in assembly, versus dynamic sysctl mach.syscall.<name> resolution here).

What stays ours permanently

The honest counterweight: the two files that actually cost maintenance are the two with no upstream. dispatch_kevent.c (1,069 lines) has no Apple counterpart whatsoever — XNU implements EVFILT_MACHPORT in the kernel, so there is nothing in libsyscall to port. And the trap and FreeBSD-glue halves of mach_traps.c (~1,130 lines: sysctl-backed host_info, reboot(2), POSIX sem_t, mmap) are FreeBSD-shaped by construction. Adopting everything Apple offers leaves both untouched.

So the realistic outcome is ~16 files vendored-and-tracked — 12 of them net-new capability rather than replacements — ~25 headers gaining an upstream to diff against, and ~1,400 lines staying hand-maintained forever. Hand-written line count barely drops. The win is new capability at zero authorship cost, not deletion.

So “revert to open-source components instead of reimplementations” maps most cleanly onto libxpc: XPC did not exist before 10.7, so pre-10.7 launchd, syslogd, notifyd and ASL are genuine Apple open-source releases that never referenced it.

3. Where dispatch and XPC are used today

Verified for the configd / networking / libmach group (survey, 2026-09-01):

This entire group uses no XPC at all. The only xpc_ hits are two comment lines in libmach/include/mach/message.h. Counts for launchd, syslog, Libnotify and CoreFoundation are still the raw grep figures and should be assumed inflated until their surveys land.

libmach bridges for libdispatch, not on it

dispatch_kevent.c has 17 mentions of dispatch_, all in comments; its only non-comment reference includes its own header. It implements kevent_qos() and struct kevent_qos_s so unmodified Apple libdispatch compiles against Apple-shaped APIs. Its Makefile links execinfo and nothing else.

The dependency runs one way: libdispatch needs libmach, not the reverse. Removing libdispatch would leave this file unused, not broken.

The binding constraint is public API, not implementation

SCDynamicStore.h:249         SCDynamicStoreSetDispatchQueue
SCPreferences.h:246          SCPreferencesSetDispatchQueue
SCNetworkReachability.h:140  SCNetworkReachabilitySetDispatchQueue

Three installed public headers declare dispatch_queue_t parameters. These are Apple public API; removing them breaks source compatibility with unmodified Apple code, which is the project’s reason for existing. A minimal dispatch_queue_t shim would be needed even with libdispatch gone. The heaviest implementation site is SCNotify.c:345-408, a DISPATCH_SOURCE_TYPE_MACH_RECV source — the one place in this group that consumes libmach’s EVFILT_MACHPORT bridge.

3b. For much of the tree, “revert to 10.6” is a category error

Verified survey of the IOKit / driver group (2026-09-01):

Zero real XPC API calls across all six. The -lxpc on libIOKit is a false positive: IOKitMatching.c uses nvlist_* to decode the ioregistry property bag, and that lives in src/libxpc/subr_nvlist.c — a vendored fork of FreeBSD’s own libnv. Dropping libxpc means repointing at base -lnv.

The entire libdispatch surface for this group is two files: libIOKit/IOKitNotify.c and mDNSResponder/mDNSPosix/mDNSConfigStore.c. Everything else is comments, __APPLE__-guarded dead code, unshipped test binaries, or transitive linkage through libIOKit’s public header.

Boot-path risk in this group is materially lower than the syslogd precedent: four components are RunAtLoad, but none of the dispatch calls on those paths is a synchronous IPC or blocking wait — they are queue and source construction. mDNSResponder’s is additionally non-fatal, with a routing-socket fallback.

3c. launchd needs deletion, not reverting

Verified: this tree carries launchd-842.92.1 (OS X 10.9, the last open-source launchd) — provenance headers in all three Makefiles, plus 842-only content (jobmgr_new_xpc_singleton_domain, jetsam bands, waiting4attach). Not 258.

Verified against upstream: launchd-258.25 has no dispatch_ and no xpc_ anywhere — its loop is a direct mach_msg on a port set, and Mach readiness arrived through case EVFILT_MACHPORT in kqueue. So 10.6 launchd was self-contained on kqueue + Mach, even though libdispatch shipped in 10.6.

A stale premise worth knowing about

runtime.c:203-226 explains that demand_port_set was moved to a dispatch MACH_RECV source because FreeBSD’s filter table is sized EVFILT_SYSCOUNT == 13, so slot −14 could not be registered without a kernel patch. That is no longer true. The native filter exists at −16 (libmach/dispatch_kevent.c:116, registered by mach.ko), and mach_kmod/tests/test_evfilt_machport.c proves it works from a plain kqueue() on a port set — exactly launchd’s callback shape. The change reduces to a shim constant and Apple’s original one-line kevent_mod.

Sizing: ~1,500–1,800 lines deleted, ~300 rewritten; -lxpc, -lsystem_dispatch and -fblocks all drop out of the Makefile. Two changes carry real “does PID 1 still boot” risk and must be validated on hardware rather than CI: the demand_port_set re-registration, and replacing launchd_runtime2’s xpc_pipe_try_receive loop with the 258-style mach_msg loop.

But this does not free libxpc on its own

Nothing in the tree depends on launchd’s XPC surface — every daemon reaches launchd through MIG bootstrap. However, several daemons depend on libxpc’s object model and connection layer (xpc_connection_*, xpc_dictionary_*); syslog/aslmanager.tproj/aslmanager.c:374-405 is a live example. Dropping libxpc wholesale still breaks those consumers, so launchd is necessary but not sufficient.

4. CoreFoundation is not the anchor — correction

On the TARGET_OS_BSD path the run loop is already dispatch-free and Mach-free: __CFPortSet is { int kq; } — a kqueue — ports are packed pipe fd pairs, wake is a byte written to the pipe, and timers are EVFILT_TIMER. The mach_msg service path is TARGET_OS_MAC and dead here.

What genuinely remains in CFRunLoop.c: main-queue interop (one dispatch main-queue port inserted into the kqueue wait set, plus _dispatch_main_queue_callback_4CF), and a dispatch_source_t that is the only implementation of CFRunLoopRunInMode’s seconds argument. dispatch_once across 20 other files costs nothing — CF already ships _CF_dispatch_once (CFPlatform.c:1609) and wires it when __HAS_DISPATCH__ is 0.

Effort: moderate — a few hundred lines, mostly deletion, with the portability scaffolding already present. The expensive question is not CF but every caller of dispatch_get_main_queue() elsewhere in the userland, because that API’s semantics are the CF/GCD bridge. If libdispatch goes, something must re-implement the main queue, and CFRunLoop is the natural home (~100 lines, given the pipe/kqueue plumbing is already there).

Two pre-existing bugs found while verifying this

• CFRunLoop.c:690 — the BSD run loop never blocks. The function takes a uint64_t timeout parameter; the port-set branch then declares struct timespec timeout = {0, 0}, shadowing it, and passes that to kevent(). It polls with a zero timeout and busy-spins. WARNS?=0 in the Makefile means -Wshadow never fired.
• CFRunLoop.c:3259 — version-1 run loop sources never fire on FreeBSD. The Source1 arm is #if TARGET_OS_MAC … #elif TARGET_OS_WIN32 || TARGET_OS_LINUX with no BSD case. CFSocket is unaffected (it creates a version-0 source), but any port-backed source is dead.

Together these suggest the BSD CFRunLoop has not been exercised under real load. Both are worth fixing regardless of what happens to libdispatch.

5. What is known about 10.6-era launchd

Measured: our launchd has 8 files using dispatch and 5 using xpc, alongside 64 call sites into its own kqueue runtime. It is a hybrid.

Assumed, needs checking: launchd-258 (10.6) used its own launchd_runtime.c kqueue loop and did not use libdispatch — it could not, because libdispatch depends on launchd for bootstrap. If that holds, the dispatch and XPC call sites in our launchd are later additions with a documented pre-existing alternative already present in the tree.

5b. Correction: XPC adoption is far later than XPC’s existence

Libnotify 133.1.1  ->  OS X 10.10      0 xpc_ lines   <- last pre-XPC
Libnotify 149      ->  OS X 10.11     13 xpc_ lines   <- first XPC

Verified: the local copy is Libnotify-348.100.7 — macOS 26.4, imported 2026-05-16 (the VENDORED.md SHA is exactly that upstream tag object, and the working tree is byte-identical to a pristine archive of it). A revert would be a 215-version, twelve-year jump backwards.

Remove in place beats reverting, for Libnotify at least

Every XPC reference is peripheral and already inert: the entitlement gates route through xpc_copy_entitlement_for_token, which returns NULL unconditionally on FreeBSD, and the event-publisher API is a set of #define … (void)0 macros in libxpc/xpc/private.h, so the single handler that could reach NOTIFY_TYPE_XPC_EVENT is never even stored.

The public API is identical across those twelve years — 13 symbols, zero delta — and notify_register_plain (syslogd’s heaviest consumer, 13 call sites) exists in both. So the revert is possible; it is simply strictly worse. If the os_set shim is itself the burden, 133.1.1’s self-contained table.c can be lifted on its own — a much smaller change than reverting the component.

6. Two plans, not one

The two libraries are independent axes with different sizes, different risks and different payoffs. Splitting them means the cheap, zero-risk half can land without waiting on the expensive half.

Plan A — libxpc

Plan B — libdispatch

On reverting components: use old releases as reference, not replacement

Three independent surveys reached the same conclusion for three different components. Reverting is available and is worse in every case:

Note the pattern that corrects this page’s original premise: components adopted XPC years after XPC shipped in 10.7 — syslog in 10.9, Libnotify in 10.11. “Pre-XPC” never meant 10.6.

The launchd revert is still the wrong choice, but for a plainer reason: ~860 lines of vendored-file edits would have to be re-found by hand in a file that diverges by 9,540 lines (392.39) or 12,200 (329.3.3), plus the shim set and three Makefiles for a different layout. The three NextBSD-original files — launchd_plist_scan.c, launchd_early.c, forward_stubs.c — do port cleanly, as does the MACH_PORT_INDEX fix.

Use 392.39’s launchd_runtime2() as donor code for the main-loop rewrite (~150 lines of proven Apple mach_msg-on-a-port-set), and delete the XPC slab from 842 in place: core.c:10367-11717 plus two smaller blocks, ~1,475 lines contiguous.

6b. XPC adoption timeline — the premise this page had wrong

XPC shipped in 10.7. Components adopted it years later, and several never did. Resolved against Apple’s own distribution-macOS manifest, not inferred from version numbers:

6c. The vintage map, and where it actually bites

This tree spans roughly 17 years. That is worth knowing before either plan starts moving components around.

Six of the nine components surveyed here are NextBSD-original, which closes the revert question for them outright: there is no older Apple version to go back to. And across all nine there are zero xpc_* API calls — the only libxpc coupling is libIOKit’s -lxpc, which is for libnv. Dropping libxpc in this group means re-homing libnv, not de-XPC-ing anything.

Documentation drift found while establishing this — six items, filed as #154: PROVENANCE.md dates IOKitUser-907.100.13 to 10.8.5 when it is 10.9 (and 10.9 is the last pre-XPC IOKitUser, so the choice was better than documented); NOTICE.md lists wrong upstreams for libIOKit, libmach and IPConfiguration and omits WLAN, mach_kmod and bootstrap_cmds entirely.

7. Do this before either plan

1. Make the boot test gate (#87). CI has passed a kernel that bricked the box, and a userland PR while SYSLOG-RUN failed on both arches under boot_soft. Both plans’ risky phases are PID-1-adjacent.
2. Get a serial console on the VM. A PID 1 failure currently means physical LiveCD recovery with no console output.

8. Pairing with epic #145

A separate survey recommends shelving #145 as a bug fix: both its rationales were retracted, and its own acceptance criterion — a clean cold-boot wedge rate — was met by the userland EV_CLEAR fix at 22/80 → 80/80 without any of the work.

Four defects in the current fd-backed design are worth fixing either way, all verified by reading:

1. In no ticket: ipc_entry_lookup does entry = fp->f_data; fdrop(fp); return entry; — returning a pointer after releasing the reference that keeps it alive. All 17 call sites use it afterwards.
2. #150: mach_port_deallocate needs two calls per send right, leaking entries, ports and fds in long-lived daemons.
3. Security shape, from #152: any ordinary fd passed as a port name is wrapped into a receiverless port and the message is swallowed. fileport_makeport is an ENOSYS stub, so no legitimate user exists.
4. #153, concrete half: fork() leaves parent and child sharing ipc_entry structs across two spaces.

And a correction worth keeping on the record: the ten kernel counters could not have excluded name recycling, because they counted failures. A stale name resolving to a different live port is a successful lookup returning the wrong object.