Jarkko Sakkinen
Posts
4458Following
315Followers
470OpenPGP: 3AB05486C7752FE1
Jarkko Sakkinen
jarkko
@josh @osi I had the same thoughts week ago but I tend to be a bit spiky from time to time so I thought maybe I was a bit too judgemental (which happens too often). Good to hear others reflect my first views on this. Thanks for writing this.
https://social.kernel.org/notice/AnPuVswNBKAitj9wxc
https://social.kernel.org/notice/AnPuVswNBKAitj9wxc
1
0
1
@aks Making difference between "rotten looking" and "rotten" is important especially since messy but functional is always better than clean and dysfunctional. It is a psychological more so than technical challenge to remember this ;-) https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
0
0
1
@aks By following this, the rotten looking parts will get treatment within shorter timeline some commentary. This way at least not dumpsters of legacy will form...
Sometimes bad looking solution can have non-intuitive but still legit reasoning - all rotten looking is not actually rotten ;-)
These are at least my empirical learnings over the years working with open source...
Sometimes bad looking solution can have non-intuitive but still legit reasoning - all rotten looking is not actually rotten ;-)
These are at least my empirical learnings over the years working with open source...
1
0
1
@aks It is sometimes hard to identify at the time. I'd suggest more like "comment on the first scratch" approach. Every time there's any issue that should lead either to:
1. A new inline comment
2. A new test case
If you start to seek appropriate places while implementing a feature, that can lead to over-saturation of comments, which dissolves the important ones.
1. A new inline comment
2. A new test case
If you start to seek appropriate places while implementing a feature, that can lead to over-saturation of comments, which dissolves the important ones.
1
0
2
Jarkko Sakkinen
jarkko
PR for 6.12-rc7 with a fix for recently reported bug:
1. https://lore.kernel.org/linux-integrity/D5CYH0IJXX72.35A25M1YICZRP@kernel.org/T/#u
2. https://bugzilla.kernel.org/show_bug.cgi?id=219383
This bug for early weeks of the current release cycle has already landed: https://bugzilla.kernel.org/show_bug.cgi?id=219229
Right now that I don't do kernel as my main job I prioritize users instead kernel developers when picking fixes for during the cycle PR's :-) Other fixes can wait until 6.13 PR.
#linux #kernel
1. https://lore.kernel.org/linux-integrity/D5CYH0IJXX72.35A25M1YICZRP@kernel.org/T/#u
2. https://bugzilla.kernel.org/show_bug.cgi?id=219383
This bug for early weeks of the current release cycle has already landed: https://bugzilla.kernel.org/show_bug.cgi?id=219229
Right now that I don't do kernel as my main job I prioritize users instead kernel developers when picking fixes for during the cycle PR's :-) Other fixes can wait until 6.13 PR.
#linux #kernel
1
1
0
Jarkko Sakkinen
jarkko
@mrmasterkeyboard This configuration allows me to even build new version of OpenSBI for every build, i.e. I get end-to-end open source stack built by BuildRoot, and has one cable less (no separate power cable) than Raspberry Pi.
The next step I'm planning to improve this is adding JTAG probe into it :-) I have one waiting for this already.
The next step I'm planning to improve this is adding JTAG probe into it :-) I have one waiting for this already.
1
0
1
Jarkko Sakkinen
jarkko
@mrmasterkeyboard
I don't know what you mean by "green board" and "black board" but this is:
1. VisionQuest 2 RISC-V board
2. A shield providing RS-232 through USB ordered from AliExpress
3. LetsTrust TPM SPI module (Infineon SLB 9672)
I do most of kernel testing in QEMU ATM but this is my bare metal choice because single USB cable gives both power and serial link and board has jumpers to configure it to SDIO mode (i.e. all stages read from provided SD card). RISC-V is a bit irrelevant here but gives confidence that changes work in multiple platforms and not just on x86. And also slowness is a feature for catching performance regressions.
I don't know what you mean by "green board" and "black board" but this is:
1. VisionQuest 2 RISC-V board
2. A shield providing RS-232 through USB ordered from AliExpress
3. LetsTrust TPM SPI module (Infineon SLB 9672)
I do most of kernel testing in QEMU ATM but this is my bare metal choice because single USB cable gives both power and serial link and board has jumpers to configure it to SDIO mode (i.e. all stages read from provided SD card). RISC-V is a bit irrelevant here but gives confidence that changes work in multiple platforms and not just on x86. And also slowness is a feature for catching performance regressions.
1
0
1
Jarkko Sakkinen
jarkko
Edited 8 months ago
The “convenience of LSP” with kernel:
make ARCH=x86_64 O=../linux-tpmdd-clangd x86_64_defconfig
make O=../linux-tpmdd-clangd/ CC="ccache gcc" -j`nproc`
scripts/clang-tools/gen_compile_commands.py -d ../linux-tpmdd-clangd
This is least distracting way I’ve found to use it (I use it only with VSCodium when just browsing around):
- Uses host architecture (target architecture can be “whatever”).
- Uses defconfig that works well for this task.
- Does not disturb other uses of the Git tree.
E.g. I use LINUX_OVERRIDE_SRCDIR a lot with BuildRoot and usually clean kernel directory in such cases causes least troubles…
0
0
1
Jarkko Sakkinen
repeated
repeated
"I can replace you lazy fucks with spicy autocomplete."
"More than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers," CEO Sundar Pichai said on the company's third quarter 2024 earnings call. If you work...
https://jwz.org/b/ykb8
3
2
0
Jarkko Sakkinen
jarkko
Midnight Commander is still the best file manager thanks to '--printwd', which writes the last seen working directory to a file. This amazes me because it is a feature that requires almost nothing to implement.
0
0
0
Second trial:
https://lore.kernel.org/linux-integrity/20241102152226.2593598-1-jarkko@kernel.org/T/#t
It's guaranteed race-free (as patch set version does not take ops_sem into account) and for anything security usually it is just only good practice to keep functionality irreversible (one-shot) on success as repetition is bad for security ;-)
https://lore.kernel.org/linux-integrity/20241102152226.2593598-1-jarkko@kernel.org/T/#t
It's guaranteed race-free (as patch set version does not take ops_sem into account) and for anything security usually it is just only good practice to keep functionality irreversible (one-shot) on success as repetition is bad for security ;-)
0
0
0
... and a test program in Rust: https://codeberg.org/jarkko/tpm-set-locality-test/src/branch/main/src/main.rs
1
0
1
@paulthenerd My guess from this that audio parts of e.g. Thinkpad hae TCO of few euros or something :-) I.e. complete and total garbage. Better if the audio chipset did not exist at all. In fact, I often disable the laptop audio chipset from BIOS as the first thing. PC speaker at least does its job
0
0
0
@paulthenerd I only limit my endorsement to the audio port when you connect it to a stage amp (as a test case) ;-) No opinions on touch pad's they're all equally bad to me...
Audio port is no that special either. You get the same level of quality from 50 EUR audio interface. That's the main point here actually... It would not cost a lot to have better (about that sum to the retail price).
Audio port is no that special either. You get the same level of quality from 50 EUR audio interface. That's the main point here actually... It would not cost a lot to have better (about that sum to the retail price).
1
0
0