Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You're spot on here.

To also add, some (most!) vendors make dirty hacks to the kernel source, as they maintain it as a standalone tree for the most-part.

Wired the headphone jack the wrong way around? Don't bother with a new PCB revision, as deadlines are too tight, and getting things perfect seems to have no place; just hack at the driver code in a messy way and change the outputs! It's not like you're ever going to really keep the device supported for a long time anyway!

So you get layered hacks - the SoC maker adds their own hacks because their production cycles are so short. Then the OEM gets the SoC and integrates it with their board, and due to their short development cycle, hacks around any issues they have too. End result is unmaintainable spaghetti of hacks and tweaks, which mainline wouldn't touch in a million years.



If the vendor is patching kernel they probably must release their patches and proprietary drivers as GPL requires (regarding drivers they could avoid this by moving important parts into userspace).


There's two things that happen: one is adding more hacks in the kernel that while required to be released under the GPL (and sometimes are, sometimes aren't!) are never going to reach the mainline kernel in a thousand years because they are way too hacky.

The other is creating userspace blobs that get passed void* from the kernel containing (kernel) internal data structures. The problem then comes about when the kernel changes those data structures.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: