Sounds cheesy, do read on? Wi-Fi industry has progressed a lot in the last decade, it now offers multi-gigabit data rates (11ac/11ax or 11ad/11ay), up to a kilometer range (11ah), 6GHz band (6E), faster connection, and roams times, high-speed mobility, enhanced security, etc. and many more to come. And with this increasing greed for more data rates (it all started with the introduction of 11ac), the role of Wi-Fi device driver developers also has changed a lot, or rather IMHO came to an end in the traditional sense, see the underlined words below for the replacement jobs :-).
We can broadly divide the WLAN Chips into two categories High performance and Low-Power and unlike earlier days where SoftMAC (LMAC in the chip) architecture was prevalent, most of the chipsets now moved to the Full mac architecture with UMAC and LMAC within the chip with some split between Firmware and Hardware. This is applicable to both types of chipsets (Performance needs more hardware offloads, power also needs more HW offloads but in a different sense). And in some industries like IoT or ultra-low power variants, TCP/IP (likes of LWIP) and wpa_supplicant is also embedded in the chip.
Only small companies who don't have money or resources or time to do these things in the chip, go for the SoftMAC approach, but that percentage is less and the number of companies actively developing WLAN chips is reduced drastically, most involve in buying a certified chip and developing applications on top of it (This phenomenon even affects such companies see the last couple of paragraphs).
The functionality of the Wi-Fi device driver is now limited to configuring the chip settings (sending commands from user space applications to the chip) and interfacing with the TCP/IP stack, in terms of the skill needed it is equivalent to Ethernet driver skills or even less. as most of the proven concepts (Rings, NAPI, (G/T/L)SO, etc) from the Ethernet drivers are taken to Wi-Fi to achieve gigabit rates. Even though it is a driver for a Wi-Fi chipset we should be calling them Ethernet driver developers. In contrast, see my old guide to starting Linux Wi-Fi driver development for SoftMAC drivers it's becoming obsolete now.
Some companies working in the north of 10Gig went a step ahead and removed the kernel from the picture completely (from Wi-Fi PoV, it still needs a KNI module in the kernel) by using frameworks like DPDK (from Linux Foundation) where the driver resides in the user-space directly talking to the hardware (using hugetlbfs). To compete with that even the traditional Linux networking guys had to come up with XDP which uses eBPF to on-load some tasks to user-space (packet filtering decisions etc.) to avoid loading on the kernel unnecessarily by dropping packets early in the cycle (even this wasn't enough, so some have offloaded eBPF processing to the HW itself to avoid packets coming up the CPU itself). The skills needed for these user mode driver developers are completely different from developing traditional device drivers.
I have mostly focused on Linux systems but the same holds true for windows WDI driver developers, but it never had much functionality in the software like mac80211 in Linux anyway so not that much of a problem.
This trend affects a very lucrative and niche area of Wi-Fi device drivers jobs. Compared to earlier, where a good amount of WLAN protocol know-how is needed and values aren't the case anymore. That is not to say that the amount of skill has reduced, the data path is still critical but its mostly proven with the Ethernet chipsets as they pioneer the OS and Driver areas with huge demands from 40/100/400 Gig rates. So, the amount of new stuff to do in the Wi-Fi drivers without the Wi-Fi involved is low and hence need fewer people to do.
Overall, for those developers who want to get their hands on WLAN features and protocols have to move to the firmware domain that needs a different set of skills and needs serious re-skilling and also the job market is quite different for firmware developers as the attrition rate in the domain is quite low as most of the work there is specialized in a closed ecosystem. And then there is a problem of licensing and customizing the firmware as most companies keep the firmware proprietary and as a USP, which is another topic entirely affecting a myriad of companies that rely on selling SW around a proven Wi-Fi chip).
Note: There is still plenty in the wpa_supplicant/hostapd but driver developers are closer to FW and very few companies do these things proprietary way most stick to opensource software.
So, if you are a Wi-Fi driver developer interested in doing Wi-Fi work (like me), it's time to rethink your career options.
I know this is a bit controversial and it is just my point of view with spending more than a decade in this industry and was part of this transition, so, please do share your thoughts and experiences, I would love to hear more.
