Android built a new, giant moat for Linux (or "Linux" depending on your opinions about Android) in the embedded application processor space - now the "standard" board support package target for new embedded AP hardware is almost always some random point-in-time snapshot of Android. Running "mainline" Linux is hard (because the GPU and media peripheral drivers are usually half-userspace Android flavored stuff and rely on ION and other Androidisms) and bare-metal is even worse (where previously, you'd get register-level documentation, now, you get some Android libXYZ.so library).
Much of that 5M are hardware register definitions expanded into C headers. I am not sure how you'd consolidate that but it's not like that's all bespoke C code.
I sympathize, but the reality is that except for very specialized cases, (hyper) optimizing for CPU performance is unnecessary, even in the embedded space. A Cortex-M0 has roughly the same performance as a 486, and is cheap and power efficient enough to be bundled in disposable test kits, vapes, etc.
Android built a new, giant moat for Linux (or "Linux" depending on your opinions about Android) in the embedded application processor space - now the "standard" board support package target for new embedded AP hardware is almost always some random point-in-time snapshot of Android. Running "mainline" Linux is hard (because the GPU and media peripheral drivers are usually half-userspace Android flavored stuff and rely on ION and other Androidisms) and bare-metal is even worse (where previously, you'd get register-level documentation, now, you get some Android libXYZ.so library).
I don't remember there being any time in history where you got "register-level documentation".
Those boards were always accompanied by horrific binary blobs glued to a kernel form a stone age. Or Windows.
Yeah, the Linux kernel has ~12m lines of code. <1m are the core, the rest are drivers.
29 Millions according to https://www.phoronix.com/news/Linux-6.16-AMDGPU-Driver-Size
5 Millions alone for the AMD graphic driver.
Much of that 5M are hardware register definitions expanded into C headers. I am not sure how you'd consolidate that but it's not like that's all bespoke C code.
What an inefficient disaster to carry around all those drivers to run hardware that isn't on the device you're running on.
* The vast majority aren't compiled into any given kernel
* Those that are are only loaded when needed
It's not that bad
I sympathize, but the reality is that except for very specialized cases, (hyper) optimizing for CPU performance is unnecessary, even in the embedded space. A Cortex-M0 has roughly the same performance as a 486, and is cheap and power efficient enough to be bundled in disposable test kits, vapes, etc.
It's modular so you don't have to compile drivers you don't need.
Most of it is in modules that don't have to be compiled at all (and usually aren't)