For almost a decade, the Realtek RTL8723BS driver has been the elephant in the Linux kernel’s room. Added to the staging area with kernel 4.12 back in 2017, this low-cost WiFi chip component seemed destined for a quick promotion. Instead, the staging pull request for Linux 7.2 tells a different story: most of the changes are still devoted to cleaning up, fixing, and taming what many developers now call a “beast”.

The origins of a problematic driver

Support for the RTL8723BS chip arrived through reverse engineering and contributions from enthusiasts and companies integrating the component into tablets, single-board computers, and IoT devices. Its natural home was the staging area, a buffer where experimental code can mature before entering the kernel’s mainline. The driver’s architecture, however, proved challenging: non-conforming coding styles, interfaces that violate internal APIs, and resource management poorly aligned with the ever-stricter requirements of the networking subsystem. Thus, instead of quickly graduating from staging, the driver became a perpetual construction site.

Endless spring cleaning

As Linux 7.2 approaches, the staging pull request is dominated by the RTL8723BS rework. The patches deal with removing deprecated constructs, adapting to new code quality standards, and rewriting critical sections to reduce latency and improve stability. These are not superficial touch-ups: every revision uncovers further issues in a cycle that has lasted years. Entry into the formal networking subsystem — the real finish line — requires the driver to pass a much stricter examination than the one it faced in 2017.

Why it matters for edge and on-premise deployments

AI-RADAR closely follows everything that touches self-managed compute infrastructure. Chips like the RTL8723BS populate millions of embedded devices, including some edge inference nodes and gateways for local data processing. Wireless connectivity is often the only way to update models, collect logs, or transmit results in environments where cabling is impractical. An immature driver can lead to sporadic disconnections, throughput drops, or crashes that undermine the Total Cost of Ownership of a distributed plant. This driver’s saga highlights a common trade-off: saving on initial hardware costs can bring prolonged software maintenance burdens, something to consider when assembling a fleet of self-hosted devices.

The vendor factor and the lesson ahead

Realtek never fully supported this chip on Linux with official backing, so the maintenance burden fell entirely on the community. This dynamic is familiar in many embedded domains and serves as a warning for those designing on-premise infrastructures based on consumer components. The quality of open source code is often outstanding, but without manufacturer collaboration the stabilization process can become grueling. The hope is that the RTL8723BS driver will finally exit staging within a few release cycles, but its case will remain an emblematic example of what it means to rely on reverse engineering and goodwill.

Meanwhile, the Linux community continues to invest time and energy to transform a “beast” into a dependable driver, proving that the open source ecosystem can shoulder the most obscure challenges to guarantee freedom and control for users. A lesson that applies as much to a kernel as to those evaluating on-premise AI deployments.