> Is there a reason for that? If I made some weird hardware that needed custom drivers, do I target the appropriate kernel APIs then get it submitted for the next kernel version?
Yep, there's a few reasons for that:
- Broadly speaking, the Linux kernel has a generic framework for "modules" that can be loaded and unloaded at runtime. Modules can do many things, including provide device drivers. It's possible to develop and build a module separately from the kernel, and within the code of the module make use of the aforementioned targeted driver frameworks.
- However, the Linux kernel intentionally does not provide a stable API or ABI for modules. And the driver frameworks are internal unstable API as well (unlike the kernel userspace API, which is never allowed to be broken). That does not mean it is impossible to develop and release a driver independently from the kernel - in practice, a fair amount of the API/ABI changes rarely - but it makes it much less practical and convenient than contributing the driver to the kernel source tree and developing it in lockstep.
- There's a wide range of (often heated) arguments around the issue of whether there should be a stable API and ABI for (driver) modules. For now the result of a debate spanning decades is I would say a loose agreement that getting hw vendors to contribute their drivers upstream has netted various benefits, such as the ability to maintain/update the driver when vendors cease to exist, get vendors to contribute to shared frameworks, make the drivers do things the vendor never planned for (e.g. expanding support to a new CPU architecture!), allow the kernel to develop faster (want to make a fundamental change somewhere? port all the driver users in one swoop and move things forward), etc.
- Overall this has lead to an ecosystem where this is now business as usual for I'd say the majority of hw vendors, who will make "contribute the driver to Linux before we release the hw" simply part of their dev and business routine.
- Some vendors still stubbornly refuse to (or have historical legal reasons they can't) contribute drivers however and have opted to try and maintain them separately. For those cases there exist some mitigating hacks. For example a little open source glue module that sits between the kernel and a proprietary binary-only driver, and distro frameworks that will recompile the glue module at boot time to fit an updated kernel (this gets around the ABI issue, but also some hairy legal license incompatibilities). Nobody loves these, but they exist and in some cases work OK where the vendor is very active in shouldering their maintenance burden.
A few decades in, I honestly find it hard to say which approach is better for which device. For example, you could say if the OS has a stable driver API/ABI, it means the vendor can cease to exist and their old driver release for my obscure hw will continue to work. This is true, but it also means you can never fix a bug in the driver, and the driver may no longer work with a major new version of the OS (say, Win 95 to Win XP, or Win XP to Vista) or in a computer with the same ports but a different CPU arch (say, x86 to ARM). In many ways the Linux kernel is the biggest actively maintained collection of "runs old obscure hardware" drivers around today, and there are plenty of gaps to "every hw works with Windows" that are filled by it.
Practical example: Recently I wanted to digitize some of my folks' old Hi8 family video tapes. My mother's boyfriend used to do this himself with an old EyeTV video capture stick they bought for their Mac circa OS X 10.3. Its drivers ceased to work around OS X 10.6 and EyeTV never provided support for their old product for newer versions of the OS, because they moved on to newer products. The fix? Capture from Linux using the same HW. Why does Linux have a driver for it? Because all these branded capture sticks map back to a just a few popular chips built into these products, and Linux has a well-maintained driver for the entire family, while the MacOS ones are vendor-specific.
And it runs deep: The entire mythical origin story of the free software movement began with a guy at MIT being upset about a bug in the driver for their expensive laser printer and the vendor refusing to release the source code and holding the device commercially hostage. This motivated the project that gave us modern open source licensing (GNU and the GPL, the latter used by Linux) and changed the entire software industry!