config: bake netgraph + the Bluetooth stack, vkbd and cuse into NEXTBSD — no .ko tree, so nothing can autoload (#412 phase 0)

Start with config/NEXTBSD and compare its existing HID and audio blocks with sys/conf/files, sys/amd64/conf/GENERIC, and sys/arm64/conf/std.dev. Review ci/assemble-image.sh:168, tests/boot-test.sh, and the referenced Bluetooth and cuse entry points before validating the requested config options across amd64, arm64, and NEXTBSD-RPI5. Done means the kernels build, the listed config and device checks pass, boot tests record the requested Bluetooth, vkbd, and cuse results, and the kernel size delta is documented.

E16 draft id K1 · epic nextbsd/nextbsd#473

Problem

NextBSD has no Bluetooth at all (nextbsd/nextbsd#412): config/NEXTBSD carries no NETGRAPH* option, and neither amd64 nor arm64 GENERIC does either (grep -i netgraph sys/{amd64,arm64}/conf/GENERIC is empty). On stock FreeBSD that is fine because rc.d/bluetooth kldloads ng_bluetooth ng_hci ng_l2cap ng_btsocket (libexec/rc/rc.d/bluetooth:8) and ng_socket.c:281-303 kern_kldloads ng_<type> on any NGM_MKPEER for an unknown type. NextBSD deletes the whole .ko tree at image assembly (ci/assemble-image.sh:168), so every one of those paths fails — the wlan_xauth trap (#51, #52) again. Plugging in a dongle today gives a ugen with nothing to claim it.

Change

Add to config/NEXTBSD (shared by amd64, arm64 and NEXTBSD-RPI5, which includes it), with a comment block in the file's house style explaining the no-.ko-tree reason:

options 	NETGRAPH			# netgraph core (ng_base, ng_parse)
options 	NETGRAPH_SOCKET			# ng_socket: PF_NETGRAPH — ngctl/libnetgraph/hccontrol find nodes through it
options 	NETGRAPH_BLUETOOTH		# ng_bluetooth: net.bluetooth sysctls; MODULE_DEPEND of every BT node
options 	NETGRAPH_BLUETOOTH_HCI		# ng_hci
options 	NETGRAPH_BLUETOOTH_L2CAP	# ng_l2cap
options 	NETGRAPH_BLUETOOTH_SOCKET	# ng_btsocket: PF_BLUETOOTH (HCI raw / L2CAP / RFCOMM / SCO); DOMAIN_SET, never autoloadable
options 	NETGRAPH_BLUETOOTH_UBT		# ng_ubt + ng_ubt_intel + ng_ubt_rtl: USB HCI transport (class E0/01/01, Broadcom/Apple vendor-class)

Every token is stock and machine-independent: sys/conf/options:516-526, sys/conf/files:4299-4320 (ng_ubt*.c are optional netgraph_bluetooth_ubt usb), sys/conf/NOTES:813-818. All MODULE_DEPENDs resolve inside this set plus usb, which both GENERICs already bake (sys/arm64/conf/std.dev:101). No src-overlay, no patch.

Deliberately not added: NETGRAPH_BLUETOOTH_UBTBCMFW (2003-era BCM2033 firmware cdev whose firmware is unshippable, usr.sbin/bluetooth/bcmfw/bcmfw.8:54-56), and NETGRAPH_BLUETOOTH_H4/_BT3C (dead tokens — ng_h4 was removed in 2021, commit 79a100e28e).

What this does not do: nothing in the kernel builds the HCI/L2CAP graph. ng_ubt attaches a bare ubtN node; assembling ubtNhci/ubtNl2cap and wiring the btsock_* nodes is what rc.d/bluetooth did behind devd's bluetooth.conf, and on NextBSD it becomes bluetoothd's job (area 2). Until then it is done by hand with ngctl (K6).

Acceptance

• config/NEXTBSD carries the seven options above with a comment in the file's style (cite assemble-image.sh:168, ng_socket.c:281-303, #52)
• config -x of the built kernel (amd64 and arm64 legs, and the NEXTBSD-RPI5 leg) lists all seven options
• qemu boot test on both arches: ngctl list shows btsock_hci_raw, btsock_l2c_raw, btsock_l2c; ngctl types lists hci, l2cap, ubt, socket; sysctl -n net.bluetooth.version prints a number
• hccontrol read_bd_addr exits 7 with Could not find HCI nodes (usr.sbin/bluetooth/hccontrol/hccontrol.c:110-112) — i.e. PF_BLUETOOTH and PF_NETGRAPH exist; it must not say Could not create socket
• The image ships /usr/sbin/{hccontrol,ngctl,l2ping,sdpcontrol,sdpd,hcsecd,bthidd,iwmbtfw,rtlbtfw} (expected from the compat buildworld with MK_BLUETOOTH default yes, share/mk/src.opts.mk:70; verify, since the srclist plan once marked ngctl DEFER)
• Kernel size delta recorded in the PR (size on kernel before/after; estimate is ~0.4–0.5 MB, unmeasured)
• The wired em0/virtio DHCP path in the boot test is unchanged (purely additive change)
• ng_socket.c:281-303 is added to the #52 audit table as "covered by baking the BT types"

Related

• nextbsd/nextbsd#473 (E16), nextbsd/nextbsd#412 (seed, phase 0)
• #51, #52 (the lazy-kldload trap), #54 (the wlan_xauth fix, the precedent for this PR)
• K2 (CI assertions), K6 (hand verification)

---

Also in this change: vkbd (Bluetooth HID keyboards)

Merged from E16 draft H1.

Why

bthidd(8) opens /dev/vkbdctl unconditionally for every device whose HID descriptor has a keyboard page, and fails the session if it cannot (usr.sbin/bluetooth/bthidd/session.c:106-115, releng/15.1). This is independent of -u/uinput. vkbd(4) is a module on stock FreeBSD (sys/conf/files:3501 optional vkbd; not in sys/amd64/conf/GENERIC nor sys/arm64/conf/std.dev), and the stock rc.d/bthidd load_klds it (libexec/rc/rc.d/bthidd:34-38). NextBSD ships no .ko tree (ci/assemble-image.sh:168), so on today's config/NEXTBSD (which only includes GENERIC, line 1) no Bluetooth keyboard can ever attach, and the only symptom is a syslog line. Same class of bug as wlan_xauth (#51) and hms/hmt (#335), documented at config/NEXTBSD:153-159.

The rest of the bthidd sink path is already in GENERIC and inherited: options EVDEV_SUPPORT, device evdev, device uinput (GENERIC:381-383, std.dev:72-74) and device kbdmux (GENERIC:199, std.dev:49). kbd_register() auto-attaches every new keyboard, including each vkbd, to kbdmux (sys/dev/kbd/kbd.c:197-231). That inheritance is inferred, not yet observed on a shipped kernel; this ticket makes it verified.

Change

In config/NEXTBSD, next to the HID block, add:

# Bluetooth HID (E16). bthidd(8) feeds every BT keyboard into a vkbd(4)
# instance (session.c:106-115), which kbd_register() auto-attaches to kbdmux.
# vkbd is module-only upstream (sys/conf/files: optional vkbd) and rc.d/bthidd
# kldloads it -- impossible here (no .ko tree), so it must be static.
# evdev/uinput/kbdmux come from GENERIC and are the other half of the path.
device		vkbd

No overlay needed: vkbd is a stock config token. Valid on amd64 and arm64 (MI, sys/conf/files).

Acceptance

• config/NEXTBSD contains device vkbd with the comment above; both matrix legs build green.
• On the built kernel: config -x /boot/kernel/kernel | grep -E '^(device|options)[[:space:]]+(vkbd|uinput|evdev|kbdmux|EVDEV_SUPPORT)$' prints all five.
• On a booted image: /dev/vkbdctl, /dev/uinput, /dev/kbdmux0, /dev/consolectl exist; sysctl kern.evdev.rcpt_mask exists.
• A synthetic vkbd keyboard (open /dev/vkbdctl, write scancodes) produces keystrokes on the console (dmesg/tty) — this is the manual precursor of H8.

Links

• Epic nextbsd/nextbsd#473, seed nextbsd/nextbsd#412
• usr.sbin/bluetooth/bthidd/session.c, sys/dev/vkbd/vkbd.c:674, sys/dev/kbd/kbd.c:197-231
• Netgraph/Bluetooth nodes themselves are area K's ticket; this one is needed regardless of which nodes are baked.

---

Also in this change: cuse (virtual_oss / Bluetooth audio)

Merged from E16 draft A1.

Why

Bluetooth audio on FreeBSD 15 is virtual_oss(8), which is now in base (usr.sbin/virtual_oss, lib/libcuse) and exposes its mixed device through cuse(3) — a userland character-device framework. The cuse kernel module is optional in sys/conf/files:3603 (fs/cuse/cuse.c optional cuse), is not in amd64 GENERIC or arm64 std.dev, and on stock FreeBSD is kldloaded on demand (the port's rc script has required_modules="cuse"). NextBSD deletes the whole .ko tree at image assembly (ci/assemble-image.sh:168), so this is the wlan_xauth / snd_uaudio / snd_hda unbaked-leaf trap again: virtual_oss starts, finds no /dev/cuse, and exits. Same dependency for webcamd and the DriverKit-shape userland-driver plan (cuse is catalogued as org.nextbsd.kpi.CUSE in the kld-to-kext catalog), so the line pays for itself beyond Bluetooth.

Exact change

In config/NEXTBSD, next to the snd_uaudio / snd_hda block (lines ~188-240), add with the usual rationale comment:

# Userland character devices (cuse(3)). virtual_oss(8) -- FreeBSD 15's base
# audio mixer and the Bluetooth A2DP path -- creates its /dev/dsp* nodes
# through cuse. Module-only on stock FreeBSD (sys/conf/files: optional cuse),
# and NextBSD ships no .ko tree, so it must be static. MI, no MODULE_DEPENDs.
device		cuse

It reaches NEXTBSD-RPI5 through its include NEXTBSD.

Acceptance criteria

• device cuse present in config/NEXTBSD; amd64 and arm64 kernels build clean in CI
• On the qemu boot test, ls -l /dev/cuse exists after boot (add to tests/boot-test.sh alongside the /dev/sndstat check)
• virtual_oss -f /dev/dsp0 -d dsp.test -t dsp.test.ctl on the boot-test VM gets past cuse_init() (it will still die at kldload("cuse.ko") until A3 lands — record that in the test as expected-fail until then)

Links

• Epic nextbsd/nextbsd#473, seed nextbsd/nextbsd#412
• Sibling trap: nextbsd/nextbsd-kernel#51 (wlan_xauth), and the snd_uaudio/snd_hda comments in config/NEXTBSD:188-240
• sys/conf/files:3603, sys/fs/cuse/cuse.c, lib/libcuse/cuse.3 (releng/15.1)
• Research: e16/5-audio.md section 1

---

Dependencies (E16)

• Depends on: nothing
• Blocks: nextbsd/nextbsd#475 (K2), nextbsd/nextbsd#476 (K3), nextbsd/nextbsd-userland#203 (K5), nextbsd/nextbsd#477 (K6), nextbsd/nextbsd-kernel#233 (K8), nextbsd/nextbsd#478 (B4), nextbsd/nextbsd-kernel#234 (B5), nextbsd/nextbsd-userland#207 (D2), nextbsd/nextbsd-userland#214 (H2), nextbsd/nextbsd#484 (H8), nextbsd/nextbsd#485 (A2), nextbsd/nextbsd-kernel#236 (A3), nextbsd/nextbsd-userland#218 (A4), nextbsd/nextbsd-userland#219 (A5), nextbsd/nextbsd-kernel#237 (A6), nextbsd/nextbsd#486 (A8)

Draft ids (K = kernel & hardware, B = engine/BLE, D = bluetoothd/CLI, H = HID, A = audio) are listed with their issue numbers in nextbsd/nextbsd#473.