Conversation
Greg K-H
gregkh
The new EU regulation requiring longer "full support" (5 years) for mobile devices is going to be fun!
Companies will have to update their kernel to a newer version over the lifespan of the device in order to stay in compliance.
As I heard recently in a meeting with one Android vendor, "Android updates consist of over 2000 programs updated to the latest version, what's so hard about adding 1 more to it?"
So if the requirement from Android to have a 6 year supported kernel version is now gone, maybe we don't have to do it upstream either? That will make so many people very happy.
Also, Apple has been doing this for a long time for their devices, why do people feel it is somehow impossible? :)
https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/12797-Designing-mobile-phones-and-tablets-to-be-sustainable-ecodesign_en
Companies will have to update their kernel to a newer version over the lifespan of the device in order to stay in compliance.
As I heard recently in a meeting with one Android vendor, "Android updates consist of over 2000 programs updated to the latest version, what's so hard about adding 1 more to it?"
So if the requirement from Android to have a 6 year supported kernel version is now gone, maybe we don't have to do it upstream either? That will make so many people very happy.
Also, Apple has been doing this for a long time for their devices, why do people feel it is somehow impossible? :)
https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/12797-Designing-mobile-phones-and-tablets-to-be-sustainable-ecodesign_en
0
52
60
@wagi Yes, the 5 year period starts _much_ later than what almost all Android companies currently feel they need to support, which again, is going to force them to have to update their kernel to a new version to stay in compliance as there will not be a secure/supported kernel that lives that long (and no Android vendor can actually do it on their own from what I have seen and heard from them.)
0
0
2
@juliank @wagi Yes, they do (for newer versions of Android), but the issue is that the upstream kernel stops supporting kernel versions.
So should Google attempt to support kernel versions for many years all on their own? That's up to them but it's something I would never advise them to do as that's an unwise and thankless task.
The companies that should be doing this are the chip OEMs that provide the hacked-up SoC kernels to the vendors. They are the ones that actually got paid for that kernel and support from the vendor. But they know they too can't even attempt to do that as they refuse to do it today.
So the only real solution is to jump to a newer kernel version. That is something the SoC vendors, and Google can support and do today.
Again, it's just one more package to update, not anything magic or scary about the kernel here.
So should Google attempt to support kernel versions for many years all on their own? That's up to them but it's something I would never advise them to do as that's an unwise and thankless task.
The companies that should be doing this are the chip OEMs that provide the hacked-up SoC kernels to the vendors. They are the ones that actually got paid for that kernel and support from the vendor. But they know they too can't even attempt to do that as they refuse to do it today.
So the only real solution is to jump to a newer kernel version. That is something the SoC vendors, and Google can support and do today.
Again, it's just one more package to update, not anything magic or scary about the kernel here.
0
0
1
@Conan_Kudo @tylersaunders ChromeOS has that "rule" and it's regularly flaunted for some subsystems for various, good, reasons.
As you well know, a SoC is a few orders of magnitude more complex than your normal server/desktop so the amount of drivers and kernel code to control it is almost double, and the code sharing from common IP blocks is much less than ideal. So trying to get all code upstream is a task that no SoC vendor seems willing to attempt until much later in the device cycle.
Yes, it would be cheaper and faster to do the work up front to get the code upstream, but SoC vendors have code to burn (actual quote from a QCOM manager to me) and no individual project wants to take the time-hit to save future products time on their upstream work (i.e. short term vs. long term incentives.)
The only real solution is if vendors put in their contracts "code must be upstream" before they buy the chips, that's what fixed it in the Enterprise server space decades ago. But right now, due to an almost monopoly in the SoC market, no one can afford to add that to contracts when making a new phone.
So you have it all here, technical complexity, short-term product deadlines, too much money to care about the problem, and monopolistic markets. Something for everyone to complain about and no single way to solve it.
As you well know, a SoC is a few orders of magnitude more complex than your normal server/desktop so the amount of drivers and kernel code to control it is almost double, and the code sharing from common IP blocks is much less than ideal. So trying to get all code upstream is a task that no SoC vendor seems willing to attempt until much later in the device cycle.
Yes, it would be cheaper and faster to do the work up front to get the code upstream, but SoC vendors have code to burn (actual quote from a QCOM manager to me) and no individual project wants to take the time-hit to save future products time on their upstream work (i.e. short term vs. long term incentives.)
The only real solution is if vendors put in their contracts "code must be upstream" before they buy the chips, that's what fixed it in the Enterprise server space decades ago. But right now, due to an almost monopoly in the SoC market, no one can afford to add that to contracts when making a new phone.
So you have it all here, technical complexity, short-term product deadlines, too much money to care about the problem, and monopolistic markets. Something for everyone to complain about and no single way to solve it.
0
1
2