Drivers: The 200KB Border Wall
You spend $2000 on a laptop. It has a 12-core CPU, 32GB of RAM, a discrete GPU, WiFi 6E, Bluetooth 5.3, a fingerprint reader, and an NVMe drive that reads at 7 GB/s.
You install an operating system that is missing one driver. The WiFi driver. A file that weighs approximately 200 kilobytes.
Your $2000 laptop is now a typewriter from 1983. It has no network. No internet. No updates. It cannot download the driver it needs because it cannot connect to the network it needs the driver for. You must find another machine, download the driver to a USB stick — formatted as FAT, naturally — walk it over, and install it by hand.
200 kilobytes. That is the distance between “all features” and “expensive paperweight.”
We have discussed why we call them drivers. We have discussed what happens when drivers are blobs. Today we discuss why that 200KB file cannot cross borders, why vendors weaponize this, and why the driver is the most effective wall in computing.
Why You Cannot Copy a Driver Between Operating Systems:
You cannot take a Windows WiFi driver and use it on Linux. You know this. But you may not know why. It is not a format issue. It is not an architecture issue. It is a language issue.
Every operating system defines its own internal language for drivers. The kernel exposes functions, structures, and interfaces that drivers must use to talk to the hardware and report back to the system. These interfaces are called the kernel API (for source code) and the kernel ABI (for compiled binaries).
Windows has WDM and WDF — the Windows Driver Model and the Windows Driver Frameworks. These are stable. Microsoft promises that a driver compiled for Windows 10 will work on Windows 11. Vendors love this. They write one driver, compile it once, and ship it for years.
Linux has the opposite policy. The Linux kernel has no stable internal API. This is not an accident. It is not neglect. It is a documented, deliberate, philosophical position. The kernel source tree contains a file called stable-api-nonsense.rst — yes, that is the real filename — in which the kernel developers explain that a stable API would prevent them from fixing bad interfaces, improving performance, and removing dead code.
Linus Torvalds said it in 1999: when vendors use binary-only modules, “it’s THEIR problem.” The solution is not to freeze the kernel’s internals. The solution is to put the driver in the mainline tree, where it gets updated alongside everything else.
FreeBSD has its own driver framework: newbus, with its own device structures, its own bus methods, its own way of probing and attaching devices.
OpenBSD has a similar but distinct framework. NetBSD has yet another.
This means:
| Source OS | Target OS | Can you copy the driver? |
|---|---|---|
| Windows | Linux | No |
| Linux | Windows | No |
| Linux | FreeBSD | No (different kernel API) |
| FreeBSD | OpenBSD | No (different kernel API) |
| FreeBSD | NetBSD | No (different kernel API) |
| OpenBSD | NetBSD | No |
| FreeBSD | Orbis OS (PS4) | No (Sony’s fork, proprietary API) |
| FreeBSD | Prospero (PS5) | No (Sony’s fork, proprietary API) |
| MINIX (Intel ME) | Anything | No (Ring -3, you cannot even see it) |
| TempleOS | Anything | No (there are no drivers to copy) |
Not even between the BSDs — three operating systems that share a common ancestor, use the same license, and have developers who read each other’s code. A FreeBSD network driver will not compile on OpenBSD. The structures are different. The bus attachment methods are different. The network stack interfaces are different. You must port the driver, which means rewriting every interaction with the kernel.
The driver is not a file. The driver is a conversation with a specific kernel, and every kernel speaks a different dialect.
The License Wall:
Even when the code is open and the APIs could theoretically be adapted, there is another wall: licensing.
The Linux kernel is licensed under GPLv2. The GPL is viral — any code that links against GPL interfaces must also be GPL. This is by design. It ensures that improvements flow back to the community.
The BSD license is permissive. You can take BSD code, modify it, and use it anywhere — including in proprietary products, including in GPL projects. Code flows freely from BSD to GPL.
But the reverse is illegal. GPL code cannot be relicensed under BSD. If an algorithm is implemented in Linux’s GPL-licensed mac80211 wireless stack — say, a rate control algorithm that determines how fast your WiFi connection negotiates speeds — that algorithm cannot be copied into FreeBSD’s net80211 stack, which is BSD-licensed.
The code exists. It is open source. You can read it. You can study it. You cannot use it.
| Direction | Legal? |
|---|---|
| BSD code → GPL project | Yes |
| GPL code → BSD project | No |
| Dual-licensed code → either | Yes (rare) |
This is a one-way door. BSD feeds GPL. GPL does not feed BSD. Every algorithm implemented only in Linux’s wireless stack is an algorithm that BSD developers must reimplement from scratch, using only the published IEEE 802.11 specifications and their own engineering. They can see the Linux implementation. They cannot touch it.
Intel understood this problem. Their iwlwifi driver is dual-licensed — both GPL and BSD. This allows FreeBSD to use the same driver source. It is one of the few vendors that made this choice. Most did not.
FullMAC vs. SoftMAC: Who Runs Your WiFi?
When your laptop connects to WiFi, someone must run the 802.11 protocol — the management frames, the authentication handshakes, the channel scanning, the rate negotiation. The question is: who?
In a SoftMAC design, your operating system’s kernel handles the MAC layer. On Linux, this is the mac80211 subsystem. On FreeBSD, it is net80211. The WiFi chip is a radio that sends and receives frames. The intelligence — the protocol logic — runs on your CPU, in kernel code you can audit.
In a FullMAC design, the chip’s firmware handles the MAC layer. Your kernel sends high-level commands (“connect to this network”) and the firmware handles the details. The protocol logic runs on a tiny CPU inside the WiFi chip, in firmware you cannot audit.
| Aspect | SoftMAC | FullMAC |
|---|---|---|
| MAC layer runs on | Host CPU (kernel) | Chip firmware |
| CPU usage | Higher | Lower |
| Auditability | Full (open source stack) | None (firmware blob) |
| Attack surface | Kernel code (auditable) | Firmware (black box) |
| Example driver | ath9k (Atheros) | brcmfmac (Broadcom) |
| Example stack | mac80211 (Linux) | Firmware-internal |
Most modern devices today are SoftMAC, but many popular chips — especially Broadcom’s — are FullMAC. This means the most critical network protocol on your machine runs in firmware you did not write, cannot read, and cannot patch.
We covered the security implications in the blobs post. Here is the portability implication: when a chip is FullMAC, the driver is simpler — it just sends commands to firmware. But the firmware itself is a black box that ties you to whatever the vendor provides. If the vendor provides firmware for Linux and Windows only, your BSD gets nothing.
The Vendor Hostility Hall of Fame:
Not all vendors are equal. Some provide open drivers and dual-license their code. Some provide nothing and dare you to reverse-engineer them.
Broadcom — The historical worst offender. Their proprietary wl driver works only on older devices and uses its own MLME stack, bypassing the kernel’s mac80211 entirely. In 2010, Broadcom released brcm80211, later split into brcmsmac (SoftMAC, PCIe) and brcmfmac (FullMAC, SDIO/USB). Progress, but incomplete. The brcmfmac firmware is not fully open-source and not always licensed for redistribution. FreeBSD had no working Broadcom WiFi driver for modern chips until February 2026, when one developer used AI assistance to port brcmfmac via the linuxkpi layer.
Realtek — The cheap chip vendor. Realtek WiFi chips are in every budget USB adapter and half the laptops on Earth. Their approach to open source: dump the SDK source code on GitHub and walk away. The community maintains rtl8xxxu in the kernel, rewriting Realtek’s code into something that works with mac80211. The driver lacks 40MHz channel support and power management. Realtek does not care. The chips cost $0.50 and the community does the work for free.
Qualcomm/Atheros — The closest thing to a friendly vendor. ath9k is fully open source with no firmware blobs — a SoftMAC driver where every line of code is auditable. It is the gold standard. But newer chips (ath11k, ath12k) require firmware. The trend is clear: even the good vendors are moving toward FullMAC and firmware blobs.
Intel — The pragmatist. Dual-licensed drivers. Works with the FreeBSD Foundation to port iwlwifi via linuxkpi. Provides firmware for all platforms. Not perfect, but the least hostile of the major vendors.
| Vendor | Open Driver | Firmware Required | BSD Support | Attitude |
|---|---|---|---|---|
| Intel | Dual-licensed | Yes | linuxkpi port | Cooperative |
| Qualcomm/Atheros | GPL (ath9k: blob-free) | Newer chips: yes | Limited | Declining goodwill |
| Broadcom | GPL (partial) | Yes (restricted) | Recent linuxkpi effort | Hostile |
| Realtek | GPL (community-maintained) | Yes | Minimal | Indifferent |
| NVIDIA (GPU) | Proprietary / nouveau | Yes | Minimal | Actively hostile |
The LinuxKPI Hack:
FreeBSD made a pragmatic decision that reveals the state of the driver ecosystem.
Rather than write native FreeBSD drivers for every new WiFi chip and every new GPU, FreeBSD built linuxkpi — a compatibility layer that implements Linux kernel interfaces on top of FreeBSD’s kernel. This allows Linux driver source code to compile and run on FreeBSD with minimal modifications.
The drm-kmod package uses linuxkpi to run Intel and AMD Linux graphics drivers on FreeBSD. The iwlwifi port uses linuxkpi to run Intel’s Linux WiFi driver on FreeBSD.
This works. It is also an admission.
FreeBSD cannot keep pace with Linux driver development. Linux has thousands of contributors and direct vendor engagement. FreeBSD has a smaller team. The gap in hardware support was widening every year. linuxkpi is FreeBSD’s answer: if you cannot write your own drivers fast enough, borrow Linux’s.
The cost is dependency. FreeBSD’s driver support is now partially downstream of Linux. When Linux changes an interface, linuxkpi must be updated. When a Linux driver gets a new feature, FreeBSD gets it later — or not at all. The BSD that prides itself on independence now depends on the GPL ecosystem for hardware support.
In the past, FreeBSD maintained its own bespoke Intel graphics drivers. That era is over. The linuxkpi layer is the present and the future. Independence has a cost, and that cost is hardware that does not work.
The Lesson:
The driver is the smallest critical component in your system. A few hundred kilobytes that determine whether your hardware is a modern computer or a vintage display piece.
That file cannot cross borders because every operating system chose a different internal language for talking to hardware. Linux chose instability-by-design, reasoning that forcing drivers into the mainline tree produces better code. Windows chose stability, reasoning that vendors need predictable interfaces. The BSDs each chose their own path, and now they cannot share drivers even with each other.
Vendors exploit this fragmentation. Write one driver for Windows. Maybe one for Linux. Everyone else gets nothing. The cost of supporting another OS is not the engineering — it is the maintenance. A driver is not a one-time deliverable. It is a commitment to track a moving kernel API forever. Most vendors will not make that commitment for operating systems with single-digit market share.
The license wall makes it worse. GPL code cannot flow back to BSD. Algorithms implemented in Linux’s wireless stack must be reimplemented from scratch by BSD developers who can see the solution but cannot legally use it.
And then there is the architecture split — FullMAC chips that hide the protocol in firmware, vendors who dump SDK code and walk away, and a trend toward more firmware and less auditability.
200 kilobytes. That is the wall. It is not made of code. It is made of incompatible ABIs, incompatible licenses, and incompatible incentives. And it is the most effective border in computing.
In the Republic of Derails, we standardized on one kernel, one API, one license, and one hardware vendor. The vendor is us. The hardware works. Nobody else can use our drivers either, but that is by design, not by negligence.
— Kim Jong Rails, Supreme Leader of the Republic of Derails