Linked by Thom Holwerda on Mon 13th May 2013 12:42 UTC
Google The only thing from the interview I care about: "We are thinking about how to make Android handle updates better. We see ways we can do this. It's early days. We're talking with our partners and working our way through it. We need time to figure out the mechanics, but it's definitely an area of focus for me and for the team." We've seen empty promises about this before, though.
Permalink for comment 561441
To read all comments associated with this story, please click here.
RE[3]: Re:
by darknexus on Mon 13th May 2013 17:20 UTC in reply to "RE[2]: Re: "
Member since:

In a parallel universe where SoC manufacturers have their drivers in the tree, you are correct. Would be nice if SoC manufacturers opened their drivers, but they don't want to do it.
If a driver is not in the source tree, it's probably useless for subsequent versions of the Linux kernel. Isn't this right?

Not exactly, but you are on the right track. If the driver is in kernel space (in this case as a module) then if the kernel is changed or updated that particular module binary is mostly useless. You can try forcing it to load, but it most likely will fail or cause stability issues. That doesn't mean that the module won't compile against a newer kernel if written correctly (usually they will compile against the same major release), but it does mean you can't just leave a driver binary in place across an update. This is where we get into ABI vs API. Linux's API, while convoluted, is fairly stable. The ABI, on the other hand, might as well not exist as it is constantly changing with each change in a kernel. If I compile a module for my kernel and you compile one for yours, even if we are on the same kernel version, our modules will not work on one another's installations. Any slight change in the config has the potential to break a binary module in unforseen, sometimes seemingly unrelated, ways.
Unfortunately in this situation, ABI is more important than API. If Google pushes an update which changes the kernel (even if it doesn't update it to a newer version), it will break any OEM driver binaries the device requires.
The ideal solution would be to move as many drivers out of kernel space as possible, but that would be one hell of a refactoring job.

Reply Parent Score: 4