Six Great Features with the Upcoming Linux 6.6 Kernel (opens in new tab)

Because the Linux kernel does not have a stable API for modules.

The modules included in the kernel are updated whenever the API changes.

For the external modules, every time when a new kernel version is released, they may become broken and there is a lot of work to identify how to update the modules, unless one watches the kernel mail lists every day, because there is also no documentation about how to migrate the old modules to the new kernel.

The reasons for module breakage may be just the movement of some definitions from one header to another, which break compiling, but most frequently some structures gain new members or lose old members, or some functions gain new arguments or lose old arguments.

When there are new members or arguments it is hard to discover what values should be put in them, while when members or arguments are deleted it is hard to discover whether their absence must be compensated somehow, e.g. by inserting invocations to other functions.

In the worst case everything can be solved by reading the kernel source, but that takes a lot of time and those who maintain out-of-kernel modules usually do not do this as a full-time job, so they do not have time to scan every day the kernel mail lists, to see if anyone has plans to make changes that will break their modules.

As another comment explains - the vast majority of drivers are not compiled as part of a standard Linux distribution.

If you're asking why so many drivers are included in Linux's mainline repository and not maintained off-tree - the major advantage of being upstreamed is that changes to the kernel have to take your driver into account as well. e.g. anyone who changes any APIs will have to update your driver as well.

Moreover, being upstreamed certifies that your driver has gone through a non-trivial review process to be merged into the mainline and is an indication of quality/stability.

There's upsides and downsides to both approaches. I think that Linux kernel maintainers continue this approach because this forces driver maintainers to meet a minimum level of effort to get their work merged.

The Linux kernel doesn't have a stable ABI. Thus, if a kernel function signature changes, or a subsystem gets refactored, etc, drivers get updated as part of the process. If the drivers lived outside the kernel tree, they would have to be updated separately by their own maintainers. That's less efficient and prone to breakage, so generally driver modules are merged into the kernel tree. Often they can even share code with other hardware devices!

Real answer: Because Linux pretty much follows the Unix architecture, and Unix comes from an era where operating system releases were not created for a class of machines, but a specific machine. This design has worked reasonably well on the PC architecture (a class of machines) too, and the pain of adding a stable driver API outweighs the pain of having broken drivers for longer on average.

> Wouldn't it be cleaner, easier and simpler to keep those separate and add them later as "modules"?

That is exactly what Linux does. Part of building a Linux distribution is determining which modules to ship by default to your users. To the best of my knowledge, the overwhelming majority of drivers are not installed by default, and the average user will never need them.

You're literally describing something like macOS/iOS which is based around a microkernel (XNU, based on Mach). See also QNX for a non-unix OS that does this.