I rewrote the USB factory program that I've been talking about now in Rust based on my C PoC and the patterns for using io_uring while using it.

Reality hit and there's need to also talk to my program for managing things like USB hubs and ports, and images used as sources for them.

I first did JSON protocol yesterday, but it really makes the ad-hoc testing heavy. It's probably great when you have a product shipped and JSON is spoken by computers to each other but for human on terminal interaction it is a nightmare.

Today I found like ultimate solution for client-side of this: Clap. You need exactly one parser for a simple command-language, and then the commands that are typed are subcommands of that parser. And Clap has rich set of features what those contains.

Stuff coming back from program is still JSON (like listing of stuff) but since it is always data (vs not code + data) I will million great ways to fixup that part :-)

Definitely a trick to my hat of tricks that I will re-use also on other languages to get quickly ad-hoc command languages setup!

#rust #rustlang #clap

There's coding conventions, commit message conventions (kernel has one, there's conventional commits etc.) but is there log message recommendations?

I'm mainly thinking in context of system daemons (not web services or internet exposing stuff).

You can e.g., say that something "failed" or alternatively you are "unable" to perform that task etc. I've worked on this small daemon for two weeks and this is the stuff where I don't know what I'm doing.

Actually, I often have hard times reviewing log messages even as a kernel maintainer. I don't really have any guidelines for klog messages that would stick on me. Maybe there should be a document for this like we have for coding conventions and patch submissions. I dunno.

I don't know how smart it is but sometimes when I have access to a machine with no ability to change the shell, I'll add this to the end of .bashrc:

exec fish -l

I've migrated from Zsh to Fish for that same exact reason after 4.0 came out: if you cannot install packages, you can still do cargo install.

Ubiquity is really everything in debugging and hacking for me. Sometimes it goes other way around. E.g., I understand the benefits of neovim but I stick to regular vim it's usually already there (even in macOS). And in my experience it does better in extreme conditions e.g., system-on-FPGA through serial port (probably because of lack of client-server and thus less steps) 8-)

Happy 40th annivesary to #Commodore #Amiga! 🎂

🎙️PODCAST ALERT: Linaro's #virtualization expert Alex Bennée recently featured on the #OpenSource Way podcast where he talked about the emulator project #QEMU and how it helps the open source #software ecosystem. Check out the podcast here 👉 https://ow.ly/zV7h50Wtc2Z

I heard from Himmelblau developers that they are basing their work heavily on tpmrm0, which made me of course happy, as it is one of my contributions some years ago :-)

When I worked on that feature in the Spring of 2017 I thought that nobody will use it, as it is just way too niche, and I could not fully convice myself that it would bring much useful application on top of /dev/tpm0. And there was already IBMTSS and Intel TSS2.

James Bottomley did a lot for this one
in particular tricky dev management code and extended swapper I had put together also for sessions, in addition to objects.

Definitely gives me the needed boost after holiday season to look more into Himmeblau project and gives some faith that I could be useful somehow over time in that ecosystem :-)

#linux #tpm #himmelblau

io_uring's are quite awesome now that i've actually had use case based parallel IO and unpredictable changes and events in the workload and need to react bunch of things along the way. had not used this asset before so could not say really.

Nothing too fancy but I created a program called "usb-factory" meant to run as daemon and burn pre-configured images as usb mass storage appears based on image file and some policy. it's meant for instance situation where you need to burn the same image to a bunch of sticks . Obivously it can IPC status of all ongoing parallel writing jobs in order to update some kind of e.g., "burning station kiosk UI" or whatever ;-)

It's in C. I tried Rust but with a lot of string buffer construction going on I have more easier time with overflows ;-) I.e. instead of some language baked policy I want to process string buffer as follows.

Overflow happens => mark and truncate

Then with the condition of overflow marked:
2. More writes => silently drop and success
3. Read => failure
4. Check-and-read => success (as after checking it is cool to read trunacted result as you probably know why you need it).

With these cheap deferred failure semantics I can *design* the reaction to those overflow errors, and make their occurence deterministic. If you have a task manager there's just so much of doing some crazy things small strings and forwarding them as basis of comms so you really need to start to think it as a problem by itself ;-)

If I end up doing something at work with Rust in user space that is like actually needed by someone, these days I first write it in C and then rewrite it Rust.

It's just that with C you can touch anything, and thus it is extreme levels fast discover how systems do when you poke them.

In kernel things are obviously different as there is just one thing your tickling ;-)

I'm doing a small thingie to help out mutt with email using Zig. It's something i was going to do in any possible situation, so thought to spice it up like this. It's of scale that i can fully finish it and never look back zig again if i don't want to, and large enough so that i know if the language makes sense at all.

It's a bit similar case as lsiommu, i.e. scripts that have been making my life worse for over 10 years and now I'm "reimagining" them ;-)

This way I get those wiped away from my backlog and learn something new in the process.

#zig #mutt #email

lsiommu provides now also json output:

❯ build/lsiommu | head -10
Group 000 Address 0000:00:07.1 Class 060400 ID 8086:9a25 Revision 01
Group 001 Address 0000:00:07.0 Class 060400 ID 8086:9a23 Revision 01
Group 002 Address 0000:00:02.0 Class 030000 ID 8086:9a49 Revision 01
Group 003 Address 0000:00:00.0 Class 060000 ID 8086:9a14 Revision 01
Group 004 Address 0000:00:04.0 Class 118000 ID 8086:9a03 Revision 01
Group 005 Address 0000:00:0a.0 Class 118000 ID 8086:9a0d Revision 01
Group 006 Address 0000:00:0d.0 Class 0c0330 ID 8086:9a13 Revision 01
Group 006 Address 0000:00:0d.2 Class 0c0340 ID 8086:9a1b Revision 01
Group 007 Address 0000:00:0e.0 Class 010400 ID 8086:9a0b Revision 00
Group 008 Address 0000:00:14.0 Class 0c0330 ID 8086:a0ed Revision 20

~/work/github.com/puavo-org/lsiommu master
❯ build/lsiommu --style json | head -10
{
        "iommu_groups": [{
                        "id":   0,
                        "devices":      [{
                                        "address":      "0000:00:07.1",
                                        "class":        "060400",
                                        "vendor":       "8086",
                                        "device":       "9a25",
                                        "revision":     "01"
                                }]

better not to tag 1.0.0 yet to leave room for command-line interface and output formatting tweaks although now it is “feature complete”.

#linux #iommu

this felt super counter-productive:

https://github.com/puavo-org/lsiommu/blob/master/udev.c

does libudev have mechanism to get directly a packed representation?

#linux #udev #pci

I wonder if Azure has somewhere a place where you can upload endorsement certificates?

This would be for testing Himmelblau on a VM and for that use and purpose create a fake TPM vendor CA. AFAIK, Himmelblau does not yet sign anything with attestation keys but there will be a day when it will, so better to be prepared.

#himmelblau #azure #tpm

fixing up the sort algorithm mess, adding compile time option for sysfs scan (for e.g., supporting some Buildroot configurations) and perhaps --json and lsiommu should be good enough for 1.0.

It's quite light now with deps in all situations:

deps = [
dependency('argtable2'),
dependency('libudev'),
]

#linux #iommu #buildroot

https://github.com/puavo-org/lsiommu #linux #iommu

awesome, almost ready to ship :-)

this came out pretty nice and clean

❯ git ls-files
.tokeignore
CHANGELOG.md
LICENSE
Makefile
README.md
down.c
down.h
iommu.c
iommu.h
log.c
log.h
lsiommu.1
main.c
main.h
meson.build
meson.options
strbuf.c
strbuf.h
util.h

#linux #iommu

❯ wc -l *.c *.h
  317 iommu.c
   31 log.c
   70 main.c
   32 teardown.c
   26 iommu.h
   16 log.h
   11 main.h
   20 teardown.h
  523 total

Not too bad considering that iommu.c has a heap tree and radix sort implementation (I dislike qsort for anything really)

RE: https://social.kernel.org/objects/96e13d6c-6be2-4180-9bbc-f4e3fbd6a38b

I made lsiommu as I just wanted to get rid of the shitty combination of bash and python I had before:

~/work/staging/lsiommu master*
❯ build/lsiommu
IOMMU Group 0
	00:07.1 Class 060400: Vendor 8086 Device 9a25 [8086:9a25] (rev 01)
IOMMU Group 1
	00:07.0 Class 060400: Vendor 8086 Device 9a23 [8086:9a23] (rev 01)
IOMMU Group 2
	00:02.0 Class 030000: Vendor 8086 Device 9a49 [8086:9a49] (rev 01)
IOMMU Group 3
	00:00.0 Class 060000: Vendor 8086 Device 9a14 [8086:9a14] (rev 01)
IOMMU Group 4
	00:04.0 Class 118000: Vendor 8086 Device 9a03 [8086:9a03] (rev 01)
IOMMU Group 5
	00:0a.0 Class 118000: Vendor 8086 Device 9a0d [8086:9a0d] (rev 01)
IOMMU Group 6
	00:0d.0 Class 0c0330: Vendor 8086 Device 9a13 [8086:9a13] (rev 01)
	00:0d.2 Class 0c0340: Vendor 8086 Device 9a1b [8086:9a1b] (rev 01)
IOMMU Group 7
	00:0e.0 Class 010400: Vendor 8086 Device 9a0b [8086:9a0b] (rev 00)
IOMMU Group 8
	00:14.0 Class 0c0330: Vendor 8086 Device a0ed [8086:a0ed] (rev 20)
	00:14.2 Class 050000: Vendor 8086 Device a0ef [8086:a0ef] (rev 20)
IOMMU Group 9
	00:14.3 Class 028000: Vendor 8086 Device a0f0 [8086:a0f0] (rev 20)
IOMMU Group 10
	00:15.0 Class 0c8000: Vendor 8086 Device a0e8 [8086:a0e8] (rev 20)
IOMMU Group 11
	00:16.0 Class 078000: Vendor 8086 Device a0e0 [8086:a0e0] (rev 20)
IOMMU Group 12
	00:1d.0 Class 060400: Vendor 8086 Device a0b0 [8086:a0b0] (rev 20)
IOMMU Group 13
	00:1f.0 Class 060100: Vendor 8086 Device a082 [8086:a082] (rev 20)
	00:1f.3 Class 040100: Vendor 8086 Device a0c8 [8086:a0c8] (rev 20)
	00:1f.4 Class 0c0500: Vendor 8086 Device a0a3 [8086:a0a3] (rev 20)
	00:1f.5 Class 0c8000: Vendor 8086 Device a0a4 [8086:a0a4] (rev 20)
IOMMU Group 14
	55:00.0 Class 010802: Vendor 144d Device a808 [144d:a808] (rev 00)

Perhaps the most interesting implementation note is that it uses libudev for PCI discovery, instead of traversing sysfs (because the latter sucks).

Right and I made my own shitty teardown manager framwork:

/* SPDX-License-Identifier: GPL-3.0-or-later */
/*
 * Copyright(c) Opinsys Oy 2025
 */

#ifndef TEARDOWN_H
#define TEARDOWN_H

#include <libudev.h>

#define teardown(func) __attribute__((cleanup(func)))

void teardown_udev(struct udev **udev);
void teardown_udev_device(struct udev_device **dev);
void teardown_udev_enumerate(struct udev_enumerate **enumerate);

#endif /* TEARDOWN_H */

Dependencies:

❯ ldd build/lsiommu 
	linux-vdso.so.1 (0x00007f083ccd5000)
	libargtable2.so.0 => /lib/x86_64-linux-gnu/libargtable2.so.0 (0x00007f083cc8a000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f083cc5c000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f083cb8c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f083c9ab000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f083ccd7000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f083c99f000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f083c856000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f083c827000)
	libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f083c76b000)
	liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f083c745000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f083c71d000)

I can throw this to some Git repository if anyone is interested any of this. It’s really just “by me for me”, but I neither mind sharing it.

#linux #kernel #iommu

consolidated my linux pr process to a a repo, so that i can improve it over time :-) i tried printf first to generate substitutions for the mustache based email template but jq is needed here just purely for escaping the summary generated by git request-pull.

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-pull-request.git/tree/?h=main

Sometimes it would be useful if you could have multiple Git repositories in the same clone as long as they don't share files. E..g, for separating private data.

#git