4 ms·
(upstream arm-soc kernel maintainer here :) It's not really about anything Android-specific that's in the "android kernel", it's about all the other code that'
by ojn 12y ago
(upstream arm-soc kernel maintainer here :)
It's not really about anything Android-specific that's in the "android kernel", it's about all the other code that's needed for a platform to run well.
The main problem is that besides the base kernel, most mobile platforms require a lot of code that hasn't been upstreamed. In some cases, "hasn't yet", in some cases "probably never will be" -- it depends on the vendor involved if they have any such ambitions.
Most of this is drivers of various kind. Some vendors are better than others at upstreaming them and the other pieces that are needed, but nearly none of them have upstreamed sufficient amount of power management to make a real device useful and have reasonable battery life. There's also usually drivers missing for modems, etc.
And, of course, graphics is a very sore topic in this area -- no vendor today ships a phone that uses an open graphics base. Ironically enough, Nvidia is the vendor that has done best here, with work happening in the open on their DRM drivers (but no products have shipped with those drivers at this time).
The vendors that have done best are normally those who have more embedded-type platforms and not primarily mobile phone chipsets. By the time upstreaming of a mobile platform is done, the next generation is already out and nobody will build new products with the old one. It _does_ get better over time as more and more share code goes in, but most vendors have enough of a backlog that they don't see those benefits yet and as a result don't prioritize it as high as I wish they would.
Then there is of course some vendors who don't participate at all, or does very very little. The Chinese manufacturers used to be notorious here, but even some of them have started doing better as of late (Rockchip in particular, but MediaTek has started posting some patches too).
The vendor that traditionally has done best is TI, but they've gotten out of the mobile business. ST-Ericsson was making a good attempt too, and they also got out of it. Nvidia has actually been really good at working upstream on their 32-bit Tegra support, it's unfortunate that it's taken them this long to get going on the 64-bit support upstream.
- tonyg 12y agoWhen you say that there are drivers missing, does this go as far as GPL violations? Or is it not quite as toxic as that? Also, what is the situation like with regard to figuring out what has been changed in a vendor-supplied kernel vs. a generic kernel source tree? Is it reasonably straightforward to get a clean diff so you can see what was changed? Non-upstreamed hacks and bodges seem less terrible to me if it's possible to at least see how they work.
- ojn 12y agoNot necessarily GPL violations (there are cases of those too, but the bulk of it is not). It's just a matter of nobody having cleaned up the drivers enough to get them submitted for upstream inclusion. It can be quite a bit of work to do, and the next generation of product is sitting there waiting on the same people to make that work instead. You can usually download and diff the source tarballs. Some vendors keep git repos so you can see changelogs as well. There's usually a lot of noise in there though, lots of various imported vendor drivers that duplicate things, firmware files in hexdump format, etc. It's pretty common to see diffs of millions of lines.
- tonyg 12y agoThanks. The noise issue sounds pretty frustrating.
- sandGorgon 12y agocould you elaborate on what you mean by "cleaning the drivers" ? I'm really curious, because it seems that Android has built an architecture where vendor supplied drivers (binary blobs?) can be dropped in without too much changes. But upstream linux needs a considerable amount of rework to "absorb" a driver. Is this deliberate (the same reason why GCC is obfuscated) or is there a technical reason behind it ? Because Android Linux works on thousands of different platforms with a lot of stability - I'm beginning to think that the Android driver model is superior... and perhaps mainstream Linux would do well to move to that.
- mcpherrinm 12y agoI work on an embedded Linux device. Sometimes, we do whatever nasty hack we need to make this kernel work on that device -- but those changes aren't portable, aren't maintainable, and don't meet the quality requirements to be in the upstream tree. There can also be a perception it's "a waste of time" since "nobody will run another kernel on this anyways"