Hardware Support

Drivers on NextBSD arrive as kernel extensions — .kext bundles managed with kextload, kextunload and kextstat, matched to hardware by the in-kernel IOKit registry rather than by devd rules.

There is no .ko module tree to fall back on: /boot/kernel holds only the kernel itself, so anything not compiled in must arrive as a kext. See Filesystem Layout for why.

What ships per architecture

Both architectures package kexts, in NextBSD-kernel-extensions:

	amd64	arm64
Kexts	17	7
Graphics	virtio-gpu, Bochs, VirtualBox, Intel, AMD, Radeon, NVIDIA	virtio-gpu
Network	Intel wireless + Ethernet	—

Graphics (KMS)

Kernel mode-setting drivers, built from Linux 6.12 DRM sources layered on drm-kmod.

Virtual GPUs

The best-supported path today, because it is what CI boot-tests on every change.

Kext	Binds	amd64	arm64
VirtIOGraphics.kext	virtio-gpu — QEMU, KVM, UTM	✓	✓
BochsGraphics.kext	QEMU / Bochs VGA	✓	—
VBoxGraphics.kext	VirtualBox (80ee:beef)	✓	—

BochsGraphics is the reference driver: CI boots a VM and verifies it binds. VirtIOGraphics is the one that matters on Apple Silicon, since virtio-gpu is what UTM gives an arm64 guest.

Most people run NextBSD in a VM, and one of these is what puts a console on the screen when they do.

Physical GPUs

All amd64 only.

Kext	Hardware
IntelGraphics.kext	Intel integrated (i915)
AMDGraphics.kext	AMD (amdgpu)
RadeonGraphics.kext	older AMD/ATI (radeon)
NVIDIAGraphics595.kext, NVIDIACore595.kext, NVIDIAModeset595.kext	NVIDIA, 595 series

Shared support kexts

The small virtual-GPU drivers rest on a helper layer that drm-kmod does not ship, vendored and built as its own kexts so two drivers cannot collide on exported symbols:

These ship on both architectures.

Kext	Provides
IOGraphics.kext	The DRM core
IOGraphicsExtras.kext	Simple-KMS, VRAM GEM and shadow-plane helpers
IOGraphicsShmem.kext	shmem GEM plus fbdev-over-shmem
TTM.kext	The TTM memory manager
DMABuf.kext	Buffer sharing between drivers
LinuxVirtIO.kext	The LinuxKPI virtio shim — FreeBSD's LinuxKPI has no virtio at all

As the graphics work puts it: the cost of a small virtual-GPU driver is the helper layer, not the driver.

Networking

amd64 only.

Kext	Hardware
IntelWiFi.kext	Intel wireless (iwlwifi)
IntelEthernet.kext	Intel Ethernet (em / e1000)

Both have their IOKit matching tables generated directly from the driver source at build time — the PCI ID list the in-kernel matcher reads is derived from drv.c and e1000_hw.h rather than hand-maintained, so it cannot drift from the driver it binds.

Beyond these, everything the FreeBSD-derived kernel supports natively still works; kexts are for drivers that are loadable rather than compiled in.

Bluetooth

Not supported yet, and nothing to work around. There is no Bluetooth in the kernel and no daemon in userland — pairing a device is not currently possible.

It is being designed from scratch rather than ported. launchd, configd and mDNSResponder all came from open Darwin source; Apple's Bluetooth stack is blued behind the closed IOBluetooth framework, so there is nothing to vendor. The likely shape is FreeBSD's netgraph Bluetooth stack underneath a NextBSD-shaped daemon and CLI, following the same split wland and wlan(8) already use for wireless — see Wireless Networking for what that looks like in practice.

Design and phasing are tracked in nextbsd#412. Keyboards and mice (HID) come before headsets — Bluetooth audio has no FreeBSD stack to inherit, so it is a project of its own.

If you have opinions on BLE versus classic, or hardware you want working, the ticket and Discussions are both open.

Working with kexts

kextstat                                        # what's loaded right now
kextload   /System/Library/Extensions/Foo.kext
kextunload /System/Library/Extensions/Foo.kext

kextd(8) runs from launchd and handles matching at boot. Remember that kldload and kldstat do not exist here — they were deliberately removed.

Current limits

Worth knowing before you plan around any of this:

• The graphics kext series is explicitly experimental. It builds and boot-tests in CI, and BochsGraphics is verified binding inside a booted VM, but it is young code under active development.
• arm64 gets graphics, not much else. Its seven kexts are the virtio-gpu stack; the Bochs and VirtualBox drivers, every physical-GPU kext, and the Intel network kexts are amd64 only. That is the right shape for now — an arm64 NextBSD overwhelmingly runs under UTM or QEMU, where virtio-gpu is the GPU.
• Coverage is narrow by BSD standards. This is a young project — the driver list above is the list, not a sample.
• Kexts are built against the exact kernel config and source they will load into, so stock FreeBSD kmod packages will not load reliably.

See also

• Command Reference — kextstat, kextload, ioreg
• Filesystem Layout — why /boot/kernel is empty
• Project Repositories — nextbsd-kernel-modules builds all of the above