Greg K-H
Posts
273Following
88Followers
2847
@kernellogger Because we moved the date to be further away? So should that be "push back"? "move back"? I don't know, time is hard :)
2
2
2
Greg K-H
gregkh
Turns out almost no one uses extra-long LTS kernels, so let's slowly unwind from that interesting experiment:
https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=5cca06606a7dcb2a0a6b6a818072b81b21287b3b
https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=5cca06606a7dcb2a0a6b6a818072b81b21287b3b
3
14
23
0
0
2
@abergmeier @kernellogger
1) the only incompatibility is "do not send HTML email or modify the text of my message", which all email clients can be configured to disable except for Exchange. So don't use Exchange, even Microsoft kernel developers don't use it.
2) Run the tests on your end first, we provide them all for you to do so locally, don't wait for others to find problems that you could with the tools. To not do that yourself is a bit odd.
Realize that we get 200+ new kernel developers every 3 months, so these huge hurdles don't seem to be all that large to others, perhaps you need a better email client?
Have fun!
1) the only incompatibility is "do not send HTML email or modify the text of my message", which all email clients can be configured to disable except for Exchange. So don't use Exchange, even Microsoft kernel developers don't use it.
2) Run the tests on your end first, we provide them all for you to do so locally, don't wait for others to find problems that you could with the tools. To not do that yourself is a bit odd.
Realize that we get 200+ new kernel developers every 3 months, so these huge hurdles don't seem to be all that large to others, perhaps you need a better email client?
Have fun!
0
0
0
Greg K-H
repeated
repeated
K. Ryabitsev
monsieuricon
b4 0.12.0 is available
Everyone using "b4 send" must upgrade to stop hitting Python email module bugs.
https://lore.kernel.org/tools/20230120165712.rznwonw6nbfhc7fo@meerkat.local/
Everyone using "b4 send" must upgrade to stop hitting Python email module bugs.
https://lore.kernel.org/tools/20230120165712.rznwonw6nbfhc7fo@meerkat.local/
1
5
13
@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
Greg K-H
gregkh
I've happy to see how well the Steam deck has turned out, and I'm glad to see them get good press for it as well. Long-term maintenance and updates are key and the Valve developers have been doing wonderful with this:
https://www.theverge.com/23513517/steam-deck-long-term-test-valve
Now if only they would switch to use the LTS kernel releases, I'd be totally satisfied.
https://www.theverge.com/23513517/steam-deck-long-term-test-valve
Now if only they would switch to use the LTS kernel releases, I'd be totally satisfied.
0
14
28
Greg K-H
gregkh
When you attempt to rebuild the Fairphone 3 kernel on a modern distro (i.e. Arch) and you get a very odd failure when building the kernel modules, install the `aur/ncurses5-compat-libs` package and then all will work properly.
Took me forever to try to figure out what was wrong with the kernel code itself, should have realized it was the host system issue instead. Hermetic Android builds must have come later in the Android release cycle.
Took me forever to try to figure out what was wrong with the kernel code itself, should have realized it was the host system issue instead. Hermetic Android builds must have come later in the Android release cycle.
0
1
7
@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
@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
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
@never_released They have had 6 years to plan for this, it is not like this is a surprise. If it is, you need to not use those HW vendors at all as they have no idea what they are doing...
0
0
2
Greg K-H
gregkh
The 4.9.y kernel is finally end-of-life, it is gone from the tracking board.
2
99
193
Greg K-H
gregkh
@monsieuricon This is the second time this has happened, first time it broke all of my scripts that I used to generate these messes...
0
0
6