Re:64-bit ARM Kernel Development Demo on a Nexus 9
by sandGorgon on Tuesday November 25, 2014 @01:18AM
(#8656592)
could 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.
Re:64-bit ARM Kernel Development Demo on a Nexus 9
by mcpherrinm on Tuesday November 25, 2014 @03:34AM
(#8656869)
I 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"
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.