> Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linu

> Why do the kernel developers allow corporations to shove code into the tree for hardware nobody has? Google does this too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/google/Kconfig https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... To get the code ready for when the hardware is available. > I get that the corporations employ the maintainers of this code, but if that person quits or the company discontinues a product, now we're left with useless crap in the kernel. Why can't these companies just build their own modules? Why is it everyone else's problem? A lot of companies and individuals can step up to maintain the code once it's there and working. If it's important, they will and they have. Only dead-dead systems like the 80386 get removed; or, in this case, vaporware that never materialized to begin with. Modules are bad because they're code that isn't subject to the same review as normal kernel code, may be closed-source or under some obnoxious license, and probably is going to be more difficult to install than just a kernel update. So we want it to be "everyone else's problem" because that means anyone else can step up if a company fires the people maintaining the code for hardware the kernel team still wants to support. With a module, it might be the case that the module only works on some range of kernels and is very difficult to replicate its functionality on more modern ones once the original company drops out. That's not a good position to be in if you rely on being able to run modern Linux on that hardware.