Krzysztof Kozlowski
Posts
268Following
39Followers
287#standwithukraine 🇵🇱 🇪🇺 🇺🇦 🇨🇭
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social
@oleksandr @kernellogger @ptesarik @suse Although to be honest, that v2.6 (v2.6.32 to be specific) was kept as SLTS by the community till 2016.
0
0
0
Krzysztof Kozlowski
krzk
@oleksandr @suse @kernellogger @ptesarik
v4.14 is a SLTS, so it is old indeed, but we do not compare it with RHEL v4.18. Few years ago (2020) RHEL was still updating v3.10. This is the Uber-Franken-kernel we talk about.
In 2018 RHEL released v2.6 kernel. v2.6, can you imagine?
And do you know that also features get backported to enterprise distro Frankenkernels?
v4.14 is a SLTS, so it is old indeed, but we do not compare it with RHEL v4.18. Few years ago (2020) RHEL was still updating v3.10. This is the Uber-Franken-kernel we talk about.
In 2018 RHEL released v2.6 kernel. v2.6, can you imagine?
And do you know that also features get backported to enterprise distro Frankenkernels?
2
0
1
Krzysztof Kozlowski
krzk
@oleksandr @suse @kernellogger @ptesarik "Frankenkernel" is an very old kernel which consists of thousands of backports, thus like Frankenstein.
Stable kernels are not that, because they cease to exist at some point. You need to move to newer kernel, thus backporting stops. Beyond that point, it's the distro (Redhat, Suse, also Canonical for some extended support) who creates the Frankenkernel.
And if you ever want to call stable upstream a "Frankenkernel", then Suse and Redhat create Uber-super-Franken-master-kernel...
Stable kernels are not that, because they cease to exist at some point. You need to move to newer kernel, thus backporting stops. Beyond that point, it's the distro (Redhat, Suse, also Canonical for some extended support) who creates the Frankenkernel.
And if you ever want to call stable upstream a "Frankenkernel", then Suse and Redhat create Uber-super-Franken-master-kernel...
1
0
2
0
0
2
@ptesarik @oleksandr @kernellogger @suse Oh yes, the franken-kernels with selected fixes for 4 year old kernel... Or maybe even older, because Suse customers do not like to update and test their stuff (reasonable, no one likes testing!).
1
0
2
Krzysztof Kozlowski
krzk
@broonie @kernellogger @cas Any CI you want to setup requires learning its fundamentals and its tools. The CI from the forges is no different here - it only brings some different tools.
I've been setting up different CI systems (Jenkins, Buildbot, Github and Gitlab) and the forges ones are really easy to start with. Complex things are complex everywhere, so I would not call it as a problem.
Plus you can opt-out and use your own CI, via some git-forge-hooks (if we talk about testing patches during review) or directly by git hooks / git fetch (if we talk about testing applied contributions).
I've been setting up different CI systems (Jenkins, Buildbot, Github and Gitlab) and the forges ones are really easy to start with. Complex things are complex everywhere, so I would not call it as a problem.
Plus you can opt-out and use your own CI, via some git-forge-hooks (if we talk about testing patches during review) or directly by git hooks / git fetch (if we talk about testing applied contributions).
1
0
2
Krzysztof Kozlowski
krzk
@oleksandr @kernellogger That's not the problem of stable backporting process. At that stage it is not known that this was part of 16 patches features set. It is backported from Git. At this stage all the patchset-hierarchy is gone and not really important. What's in the Git tree is important.
The problem here was the original submission:
1. Mixing fixes with features in same patchset.
2. Putting fixes into the middle of a patchset.
3. And maybe: tagging commit as "Fixes" for something not being fix.
Therefore please complain to the submitter and optionally to the maintainer, not to the stable backport fix.
Otherwise please explain me why a fix for a known bug should not be backported, as I described in previous post.
The problem here was the original submission:
1. Mixing fixes with features in same patchset.
2. Putting fixes into the middle of a patchset.
3. And maybe: tagging commit as "Fixes" for something not being fix.
Therefore please complain to the submitter and optionally to the maintainer, not to the stable backport fix.
Otherwise please explain me why a fix for a known bug should not be backported, as I described in previous post.
1
0
0
Krzysztof Kozlowski
krzk
@oleksandr @kernellogger No, it is not an AI. It's simple and fixed decision: Is this commit fixing a bug in previous release? If yes, then let's backport to fix that bug.
Now you claim that "Fixes" tag is for commits not fixing bugs or bugs are not important. In the first case, Fixes tag would be added incorrectly to the commit. It is purely for fixing known bugs. In the second case, how do you know which bugs are important and which are not? All bugs are bugs which we want to fix...
Now you claim that "Fixes" tag is for commits not fixing bugs or bugs are not important. In the first case, Fixes tag would be added incorrectly to the commit. It is purely for fixing known bugs. In the second case, how do you know which bugs are important and which are not? All bugs are bugs which we want to fix...
2
0
1
@kernellogger @cas I am all in for some way of Git-forges. Not necessarily Github or Gitlab (cloud or self-hosted), but something where setting up workflows/pipelines/CI is trivial. Now, to test patches I need to set up my own CI. Other maintainer needed his own. Other needed one more. And all these CIs are not good enough, because testing patches from Patchwork or mailing list requires few additional steps. I don't want to spend my time on writing CI or CI-like-scripts to interact with Patchwork. I want to write a set of simple rules or commands to check every patch sent (or commit) and output warnings with success/error status.
One can do it easily on a Git forge.
One can do it easily on a Git forge.
1
0
1
Krzysztof Kozlowski
krzk
@kernellogger Yep, I am all in for the bots.
Checkpatch is garbage, but it is the only garbage we have, so till someone writes something better, please use it.
Checkpatch is garbage, but it is the only garbage we have, so till someone writes something better, please use it.
1
0
2
Krzysztof Kozlowski
krzk
Edited 2 years ago
Just reviewed a patch with... four comments coming entirely from my templates. No need to write anything, just hit some templates. Two out of these four comments were for not using in-kernel tools for patch submission/testing (checkpatch.pl and get_maintainer.pl). Eh. :(
2
0
1
Krzysztof Kozlowski
repeated
repeated
@marcan tbh I find this and related posts quite toxic. The IOMMU maintainers are nice guys (one of them is my team colleague) and they don't deserve to have people reading your posts getting the impression that their subsystem is crap.
In the thread you mention doing some unusual (or maybe first time) scenario with it. It's completely normal to encounter bugs in such situations and simply fix them along the way, no need to gloat about it.
In the thread you mention doing some unusual (or maybe first time) scenario with it. It's completely normal to encounter bugs in such situations and simply fix them along the way, no need to gloat about it.
2
4
25
Krzysztof Kozlowski
krzk
I announced it before on social.kernel.org, mailing lists and finally in the Linux kernel (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25223cba5aa9a536392933782d4a7df71d9093b). So one more time, same announcement:
None of the Samsung and Samsung Foundry platforms can bring any new `dtbs_check W=1` warning.
Contributor can easily test it, so sending code which introduces such warnings is considered close to sending code which does not compile. Fast step to get your maintainer grumpy.
None of the Samsung and Samsung Foundry platforms can bring any new `dtbs_check W=1` warning.
Contributor can easily test it, so sending code which introduces such warnings is considered close to sending code which does not compile. Fast step to get your maintainer grumpy.
0
1
6
Krzysztof Kozlowski
krzk
Nice follow-up of Monday's Plumber's talk - Powering up “discoverable bus-attached” devices on DT-based platforms - BoF session with the same title:
https://lpc.events/event/17/contributions/1654/
It seems @abelvesa and Bartosz have now a acceptable solution to implement.
https://lpc.events/event/17/contributions/1654/
It seems @abelvesa and Bartosz have now a acceptable solution to implement.
0
0
2
Krzysztof Kozlowski
repeated
repeated
James Bottomley
jejb@mastodon.online@linuxplumbersconf Youtube Live Stream URLs are now available on the Schedule Overview page (https://lpc.events/event/17/timetable/#all).
Find the track you want and click the paperclip on the upper right corner to bring up the Live Stream Link
2
14
2
To clarify: most likely the property is innocent here. Its account got either hacked or booking.com systems allow such hacking and fradulent sending messages to customers.
Booking.com doesn't see any problem...
Booking.com doesn't see any problem...
0
0
1
Krzysztof Kozlowski
krzk
Edited 2 years ago
Some weeks ago people got scammed on Booking.com with "confirmation of payment method" or whatever they called it. Booking.com systems allowed scammers to send to customers messages about need to pay again. Second time. Booking.com denies.
So here it is: Booking.com still is not secure and scammers are active. Message I just got:
So here it is: Booking.com still is not secure and scammers are active. Message I just got:
1
0
2
Krzysztof Kozlowski
repeated
repeated
Linaro Limited
LinaroLtd@mastodon.social
Edited 2 years ago
A talk for fresh Kernel Maintainers and anyone looking to optimize their workflow @linuxplumbersconf with @krzk
1. Get improvements to email workflow: b4, useful simple hooks for verifying commits (because checkpatch is not enough).
2. Get yourself in linux-next and get tested by community Continuous Integration/Testing.
3. Add yourself to kernel.org keyring, sign your tags and pushes (for transparency log).
4. Dump the mailing lists: use lei and lore
https://lpc.events/event/17/contributions/1498/
0
7
2
Krzysztof Kozlowski
krzk
@geert @kernellogger @corbet @monsieuricon I believe choosing manually which list to CC (e.g. to CC LKML or not) is not the way the community should work. It might work for you, but such choice should not be in general task for a human. Scripts should make this decision for you.
This means that, if anyone has to or wants to trim or extend the output of scripts/get_maintainers.pl more than once per month, then the script is doing poor or insufficient job.
P.S. Occasional adjustment of get_maintainers.pl is reasonable, but not on regular basis.
This means that, if anyone has to or wants to trim or extend the output of scripts/get_maintainers.pl more than once per month, then the script is doing poor or insufficient job.
P.S. Occasional adjustment of get_maintainers.pl is reasonable, but not on regular basis.
0
0
0