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.

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