Comment by summa_tech
6 days ago
I mean, part of that is the difference between how easy it is to build a platform in Linux vs how hard it is to get into the tree. This is actually, in my mind, a major change in the Linux development process.
Nobody expected Intel to provide employees to write support for 80386 pagetables, or Philips to write and maintain support for the I2C bus. The PC keyboard driver was not sponsored and supported by IBM. Getting the code into Linux was really easy (and it shows in a lot of the older code; Linux kernel quality standards have been rising over time), because everyone was mostly cooperating on a cool open-source project.
But at some point, this became apparently unsustainable, and the expectation is now that AMD will maintain their GPU drivers, and Qualcomm (or some other company with substantial resources) will contribute code and employees to deal with Adreno GPUs. This led to a shift in reviewer attitudes: constant back-and-forth about code or design quality is typical on the mailing lists now.
This means contributing code to the kernel is a massive chore, which any person with interest in actually making things work should prefer to avoid. What's left is language lawyers, evangelists and people who get paid to sit straight and treat it as a 9-5 job.
This is just part of the bureaucratisation of everything. The bureaucracy always try to extend its power and find ways to self-justify its existence, accaparing ressources to extend the control and bring ever more people into the fold. It's an intrinsically parasitic process that ends up killing the host in the long term.
Which is why most communist like endeavor ends up in failure. Without the necessary pruning that comes with competition, you end up in a situation where it's more profitable to get the power to control the resources and take a fee for each interactions than actually do anything worthwhile to get "rights" to resource allocation.
The Asahi and pmOS folks have been quite successful in upstreaming drivers to the kernel (even for non-trivial devices like GPU's) as enthusiast contributors with no real company backing. The whole effort on including Rust in the Linux kernel is largely about making it even easier to write future drivers.
Agreed, and I'm fairly impressed by the GPU effort. That said, it did take a very long time, even with the demonstrably extreme amount of excitement from the Linux community (Linus himself was thrilled to use a Macbook). What do you do for parts that are useful but don't get people this excited?
What really burned me on this kind of stuff was the disappearance of Xeon Phi drivers from the kernel. Intel backed it out after they discontinued the product line, and the kernel people gladly went with it ("who'll maintain this?"). Intel pulled a beautiful piece of process lawyership on it: apparently they could back it out without difficulty, because the product was never released! (Never mind it has been sold, retired and circulated in public.)
> What really burned me on this kind of stuff was the disappearance of Xeon Phi drivers from the kernel
If you depend on that hardware, you can get it to be supported again. It just doesn't seem to be all that popular.
Note that the Rust effort is mostly sponsored by Google and Microsoft, thus the 9-5 example of the OP.
Correct me if I’m wrong but I’m pretty sure the Asahi GPU driver has not been upstreamed.