Krzysztof Kozlowski
Posts
199Following
32Followers
216🇵🇱 🇪🇺 🇰🇷 🇮🇱 🇺🇦 🇨ðŸ‡
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social
Krzysztof Kozlowski
krzk
@hyeyoo Cass I remember - water, sorry :). Terra - I did not try. From all the industrial companies only Klaud had a bit of taste. Beer revolution moves slowly :) but I remember few places with some nice choice, e.g. Cocky Pub.
RE: https://social.kernel.org/objects/fee182c1-7174-4348-90bb-f7f9cf196c39
RE: https://social.kernel.org/objects/fee182c1-7174-4348-90bb-f7f9cf196c39
0
0
1
@T_X Enough of people use these kernels and benefit is rather small comparing to costs of testing it on all possible machines/setups/users, like generic kernel.org are. Testing infrastructure in Canonical is huge, but it serves their purpose, not wider community's. Growing it for every possible machine in the world (to keep with the testing coverage) for benefit of few more folks using their kernel who would not contribute anyhow except filling bugs?
0
0
2
@T_X To be more precise - Canonical has team of ~10 Linux kernel engineers working on their stable kernels (not counting the folks working on hardware enablement and hardware-specific projects). These people maintain several stable kernels, so basically they do what you asked, just not within Linux Foundation or for kernel.org.
0
0
3
@karolherbst @kernellogger News is rather confusing people thus this discussion... Every LTS Ubuntu receives possibility to use the next release's kernel, called "HWE" kernel in that LTS release. The 23.04 was with v6.2, thus the HWE is v6.2, because it comes for free for Canonical. Or with not that much effort, as doing v6.1 for LTS! v6.2 is already supported by Canonical for 23.04.
The HWE kernel (so v6.2 in LTS) will roll to the new version, once Canonical releases newer Ubuntu using something new.
Thus suggesting that:
1. They should use v6.1 in 22.04 is not accurate. There is no point of making v6.1 HWE kernel and it would be time expensive.
2. They should use v6.3, v6.4 or whatever newer in 22.04 is again not possible or just too expensive for Canonical.
3. Thus the only viable suggestion was that 23.04 used v6.1 in the first place, thus 22.04 will get it as well... but that's different discussion and @kernellogger pointed out it already - Canonical wanted the latest kernel for 23.04.
The HWE kernel (so v6.2 in LTS) will roll to the new version, once Canonical releases newer Ubuntu using something new.
Thus suggesting that:
1. They should use v6.1 in 22.04 is not accurate. There is no point of making v6.1 HWE kernel and it would be time expensive.
2. They should use v6.3, v6.4 or whatever newer in 22.04 is again not possible or just too expensive for Canonical.
3. Thus the only viable suggestion was that 23.04 used v6.1 in the first place, thus 22.04 will get it as well... but that's different discussion and @kernellogger pointed out it already - Canonical wanted the latest kernel for 23.04.
0
0
1
Krzysztof Kozlowski
krzk
Edited 1 year ago
@T_X Not everyone has some spare money for engineers full time salary in non-profit way... They already have such updated kernels, just on their website, not on kernel.org. Your suggestion would benefit community, but what would be the benefit of this to Canonical?
RE: https://chaos.social/users/T_X/statuses/110847464823963952
RE: https://chaos.social/users/T_X/statuses/110847464823963952
2
0
4
@yha sure, we'll make some announcement here for the next meeting and of course we'll send an email. Just your profile looks empty which does not help me to identify your email address or your kernel identity, so drop me a note (my kernel org email is obvious :) )
1
0
0
Krzysztof Kozlowski
krzk
Edited 1 year ago
Once you see it, you cannot unsee:
+#ifndef MSM_VIDC_EMPTY_BRACE
+#define MSM_VIDC_EMPTY_BRACE {},
+#endif
...
+static const struct of_device_id msm_vidc_dt_match[] = {
+ {.compatible = "..."},
...
+ MSM_VIDC_EMPTY_BRACE
+};
We are back to the past! To year 2000-something to be precise. This reminds me ARM Mali Linux kernel drivers which were using MALI_SUCCESS instead of return 0.
1
0
5
Krzysztof Kozlowski
krzk
Anyone around Zurich up for a beer on 3rd of August with me and @andi?
RE: https://social.kernel.org/objects/ddc0aef7-fe3b-493a-8523-af4ad17ee4e0
RE: https://social.kernel.org/objects/ddc0aef7-fe3b-493a-8523-af4ad17ee4e0
0
0
1
Krzysztof Kozlowski
krzk
Edited 1 year ago
Anyone from Samsung has some inputs on Qualcomm minidump solution? Without any feedback we'll assume Samsung is fine with Qualcomm's choices. Thread:
https://lore.kernel.org/all/0199db00-1b1d-0c63-58ff-03efae02cb21@quicinc.com/
#samsung #samsunglsi #exynos
https://lore.kernel.org/all/0199db00-1b1d-0c63-58ff-03efae02cb21@quicinc.com/
#samsung #samsunglsi #exynos
0
0
2
Krzysztof Kozlowski
repeated
repeated
K. Ryabitsev
monsieuricon
Just a regular reminder that the war isn't over, civilians are still murdered in their homes by cruise missiles, and war crimes are committed daily by the invasion force occupying the sovereign territory of Ukraine.
Until the 1991 borders are restored, all war criminals are in jail, and reparations are paid off, I will continue to #StandWithUkraine, and so should you.
Until the 1991 borders are restored, all war criminals are in jail, and reparations are paid off, I will continue to #StandWithUkraine, and so should you.
1
8
28
I am getting more and more picky on this... Why? Because it is waste of our resources. Resources of both community and company. If one team learnt the hard way how to format patches and send them to LKML, why the heck other team has to go through the same learning process? Why reviewer has to explain again and again - `git format-patch -v3 -10 && scripts/get_maintainer.pl v3-00* && git send-email v3-00*`?
1
0
1
One could imagine that the team doing contribution, maybe for the first time for them, will ask for review the older, experienced team from other Business Unit. You know, not to make the same mistakes. But no! It cannot! BUs are separate. However Open Source reviewers are not "separate" and unfortunately receive that stuff to review, with the same mistakes as the company did before.
1
0
0
Krzysztof Kozlowski
krzk
Oh, the amazing construction of silosed Business Units of big corporations. When interacting with Open Source communities, one team in some Business Unit of that company cannot learn from the past experience of some other team, because they are silosed. Separate. Thus this team makes the same mistakes other teams already did. However Open Source community sees it differently - one company sending contributions with the same mistakes. It is always okay to make a mistake, but making the same mistake again and again, is a bit waste of our time.
1
0
1
Krzysztof Kozlowski
krzk
Edited 1 year ago
Trying to sell something on Facebook marketplace: 99% of interested people are scammers. I found a pervert joy in playing with them, requiring rather small effort from my side and ending in some amusement. This one gave up just after two days off wasting his time.
0
0
1
Krzysztof Kozlowski
krzk
Edited 1 year ago
Cleanup of inactive maintainer entries is coming :) - docs: maintainer: document expectations of small time maintainers
0
3
8
@kernellogger I can add here more - why does the standard workflow (git format-patch && git send-email, or b4) work for all subsystems, but does not for net and requires changing the [PATCH] into [PATCH net-next]? What if every subsystem maintainer asks the same? [PATCH mm], [PATCH samsung-soc], [PATCH iio]! Such pattern in subject is not even visible in `git log --oneline -- PATH`. Checkpatch does not complain, either. What should poor little fellow contributing to Linux kernel do? Learn the tips and tricks for all the maintainers, so 30-50 different rules?
1
1
5