Michal Wilczynski wrote about his quest to add Rust support to the PWM subsystem. Thanks for going through that.

@kdave this should indicate which standard is used. C99 (which is quite the norm today in my bubble) has some more: inline, restrict, _Complex and _imaginary. Other than that: 30/32

@geert There is a relevant difference (and today’s situation is again different, see below):

$ time make kernelrelease
2.6.14

real	0m0.044s
user	0m0.039s
sys	0m0.006s

$ time cat include/generated/utsrelease.h
cat: include/generated/utsrelease.h: No such file or directory

real	0m0.002s
user	0m0.000s
sys	0m0.002s

That is, make kernelrelease only emitted the version determined by the source (in Makefile), while utsrelease.h also accounts for .config.

Today there are two make targets: kernelrelease and kernelversion. The first depends on .config (and thus takes CONFIG_LOCALVERSION, CONFIG_LOCALVERSION_AUTO etc. into account), the latter has the same semantic that I introduced for kernelrelease back then. See commits 6b6a462c4ab7 (“[PATCH] KERNELRELEASE depends on CONFIG_LOCALVERSION”) and cb58455c48dc (“kbuild: KERNELRELEASE is only re-defined when buiding the kernel”).

And FTR: I think the semantic and names are swapped. For me the kernel release is 6.18.0-rc4 and the version can be something like 6.18.0-rc4-00155-g4a0c9b339199.

@gregkh Oh damn, I forgot to git add

Feeling both old and proud: My first kernel patch was accepted yesterday 20 years ago!

@otte_homan @publicvoit This is how /usr as we know it today was born. “In the original Unix implementations, /usr was where the home directories of the users were placed (that is to say, /usr/someone was then the directory now known as /home/someone).” (from FHS). Your chance to keep /home/cache/apt and coin how Linux look in the future 😆

@geert @acb If the random person in Nebraska is taken out the top part might become horizontal again. I think this is where the metaphor stops … :-)

Also new in Debian 13 “trixie”, both RTC support and pinctrl-based muxing for the Raspberry Pi CM 4.

Initially we would only have the GPIO 0/1 pair for I²C, but with muxing we get both GPIO 0/1 and 44/45 pairs, with the RTC attached to the 44/45 one.

With many thanks to @ukleinek for the stellar support (public and private) over the years!

- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84b1d6cc3e4cc49f04aaacc5e0094c221a772cf0
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d72e40d41736d083e47dc50c6c2e1d59e5af6944

@codonell @gregkh @brauner I understand a tag to apply to the patch, not the resulting tree. So if said patch doesn’t need rework to apply on another branch, it’s fine to keep its tags.

After the #OpenPGP keysigning party at @embeddedrecipes with 20 registered (and several ad-hoc) participants the first signatures landed on the keyservers. The strong set size (only considering the 20 registered certificates) increased from 6 to 12.

@geert @monsieuricon If you click on Kevin in the first graph, the part that survives is there.

@geert @monsieuricon With “second path” you mean the svg without SHA-1? If so, there are too many paths and wotmate only shows the first four shortest disjunct paths. That path is actually there also when SHA-1 signatures are considered, just not relevant enough to display it.

I implemented changes for the tool that is used to manage the kernel’s #OpenPGP keyring repo. If @monsieuricon merges it, that makes my trust path degenerate from current trust paths to trust path without SHA-1. For others it’s worse …

Earlier today I released libpwm 1.0-rc1. If you’re working on a PWM Linux driver or you want to control a PWM from userspace, that’s what you should look into.

The @embeddedrecipes keysigning will be done using the Zimmermann–Sassaman key-signing protocol and the deadline for handing in your certificates to make it on the list is over. If you still want to attend, please bring paper slips with your fingerprint (and of course your passport and a pen). No need to register for that.

If you’re attending @embeddedrecipes this year in Nice (May 14-16), register for the PGP keysigning session with @a3f by sending your public key to er2025-keysigning@baylibre.com.

PGP is used to sign and (hopefully) also verify pull requests. For a big and relevant part of our community the certifications and cross signatures that are the computational base for the trust in the transferred code changes are already long established.

The problem here is that security is a moving target and the algorithms used back then are not considered secure any more. For example GnuPG (and also other OpenPGP implementations) don’t consider SHA-1 secure any more. See my blog for some effects of that on the kernel Web of Trust.