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.
Thread beginning with comment 561434
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Re:
by kurkosdr on Mon 13th May 2013 15:58 UTC in reply to "RE: Re: "
kurkosdr
Member since:
2011-04-11

No.

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?


But in any case, there have been many articles pointing out that most of the delay in the states is due to carrier certification of each update, rather than code modifications and incompatibilities with the new Android update from google.

Then why unbranded (not carrier locked) Nexus S devices took months to receive ICS? Shouldn't ICS have been served a week after it appeared on the Galaxy Nexus? Hint: Driver issues.

Edited 2013-05-13 16:01 UTC

Reply Parent Score: 4

RE[3]: Re:
by darknexus on Mon 13th May 2013 17:20 in reply to "RE[2]: Re: "
darknexus Member since:
2008-07-15

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