Posts
195
Following
32
Followers
215
Linux Kernel developer and maintainer
🇵🇱 🇪🇺 🇰🇷 🇮🇱 🇺🇦 🇨🇭
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social
@cas @samueldr Patch based workflow is not necessarily easy, although there are tools making it easier (like b4 mentioned by @cas), but it is the one which is the easiest for us. Now, I have been sending patches with git send-email for some years and I have sent quite a few (if you read LWN then you know :) ), and I never had single problem with git send-email. Neither with git format-patch. I find them trivial. Now and long time ago.
I have been also working with people complaining a lot about Git, that it is too complicated and too difficult. I would say all of these - Git is too difficult, git send-email is too complicated - is the same complaining as "C is too difficult" or "using shell is too complicated": valid statements for a regular user, but not really for software developer in this domain. When learning something new, it is pretty often difficult and complicated. This is why it is called learning...
0
0
2
@Kirabug But website does not give such awesome abilities to track users, spam with notifications and invade their privacy. This is why it is better in the app. To track you. :)
0
0
0

Krzysztof Kozlowski

Hey @linuxfoundation
Do you plan to upload more photos of EOSS 2023? I see pictures from only the first two days of EOSS, not even complete two days... Other days are not uploaded at all. As you can see in the link below, count stays at 150 pictures is since last Thursday:
https://www.flickr.com/photos/linuxfoundation/albums/72177720308904909/page2
#eoss2023 #elce2023 #EmbeddedOSSummit
0
0
2
@shanmukhateja I think the post under link listed what was present in initial submission. The Adreno GPU patches were recently posted here: https://lore.kernel.org/all/20230628-topic-a7xx_drmmsm-v1-0-a7f4496e0c12@linaro.org/
0
0
1

Krzysztof Kozlowski

Edited 1 year ago
10% of commits in Linux kernel v6.4 came from Linaro engineers. It is a nice result for such a small group of kernel engineers.
https://www.linaro.org/blog/linaro-contributions-to-the-6-4-linux-kernel-release/
0
1
8

Krzysztof Kozlowski

Edited 1 year ago
It was great to see at the EOSS 2023 commitments from some ARM64 SoC manufacturers to upstreaming their SoCs. It was visible in the conference talks but also I got such clear vibes during the talks behind the scenes.
What was a bit missing is a story of Qualcomm which recently is heavily visible upstream - both directly and through the Qualcomm Landing Team in Linaro. November last year Qualcomm released its newest, shiniest mobile SoC: the Snapdragon 8 Gen 2 (SM8550).
And guess what happened? The next day you could find all the Linux kernel support for this new SoC on the mailing list. The newest SoC was released with upstream support at the same time. There is also story from @superna9999: https://www.linaro.org/blog/upstream-linux-support-now-available-for-the-the-qualcomm-snapdragon-8-gen-2-mobile-platform/
#eoss2023 #elce2023 #EmbeddedOSSummit
1
15
39
@minipli @gregkh @kernellogger Timelines indeed sometimes do not align. Consider Ubuntu 18.04 (Bionic) which was using v4.15 kernel because of the timeline and Canonical was basically doing LTS on their own for four years. But timing cannot justify distro/vendor staying on chosen kernel for 4 years, instead of going to next LTS. It's distro's or vendor's deliberate choice - they don't want to update the kernel in released distro version even once per few years. And that choice is here being challenged.
1
0
1

Krzysztof Kozlowski

Edited 1 year ago
@kernellogger Been there. Request to backport few KVM patches for new AMD processors to distro v4.15 kernel resulted in 500-big patch bomb... and I was only half way. Then we gave up and managed to convince customer that it's not a feasible solution.
1
0
6

Krzysztof Kozlowski

Edited 1 year ago
Room full of people - I certainly didn't expect such big audience. #eoss2023 #elce2023 #EmbeddedOSSummit
1
0
7

Krzysztof Kozlowski

Edited 1 year ago
@kernellogger @mupuf the forges are not the answer. We already have tools which report such failures (LKP/kernel test robot), so either the tree was not on kernel.org (thus not covered by LKP by default) or reported warning was ignored.
What we maybe miss is a tool or part of workflow, which will check for how long patch was in next, before sending to Linus. And loudly complaining if it's less than two weeks.
1
0
0

Krzysztof Kozlowski

Edited 1 year ago
@pdp7 not bad shot. Looks like I'm swallowing something, maybe a comment about non-tested bindings :)
1
0
3
@monsieuricon xkcd nicely pointed out silliness of usual password approaches - difficult for us to remember, easy for machines to break: https://xkcd.com/936
0
0
0

Krzysztof Kozlowski

Updating my CV, collecting references, debt register extract, salary details and writing motivation letter. People do crazy stuff to get a nice apartment in Switzerland.
1
0
1
I would also dare to add â‚¿ (BTC) to above equations for greater impact. Let's think big! :)
0
0
2

Krzysztof Kozlowski

I love it. And think how many other equations and laws of physics can be improved with adding AI. Ohm's law? Dude, please, I = (V + AI) / R. Newton's second law? Easy peasy, F = m * a * AI. Maxwell equations - don't get me even started...
2
0
3

Krzysztof Kozlowski

Edited 1 year ago
@conor no, it was sent only to me, not to public lists, for some reason. And I don't know the license now. Is it GPL?
The code looks like a very good template, with comments what has to be added and checked to match real DTS.
0
0
0

Krzysztof Kozlowski

> [2]: Snippet created with the assisstance of GPT-4

So it began...

That was quite nice Devicetree source snippet. Can be entirely incorrect though, just looks good.
1
0
2

Krzysztof Kozlowski

Some useful commands for daily usage of DT schema helpful in efficient checking of the DTS files:
https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
0
4
5
@sj Unfortunately people in general: don't run checkpatch, don't read Submitting Patches doc, don't read other relevant docs, don't build test on many setups, don't test patches (in case of DT bindings). Sure, I can add one more doc for them to ignore :)
0
0
2
@ljs @conor That's a good habit, I have the same, but we still can forget it from time to time. The point is not to be offended when someone tells me to compile the code or to run checkpatch.pl.
1
0
1
Show older