@avlap2 hell no, it's stuff that i get paid for :-) it's a fucking nightmare to sometimes even compile with that. would not ever try to use it for anything serious that someone is paying for

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.

As an extension to the current functionality i'd like at recording of USB devices so that you could check optionally for a stick does it have a working image (i.e. record success, IO error and detachment) e.g., for weird situations, i.e. have knowledge base which of the sticks are faulty and which can be safely shared or at least to the best of knowledge.

In this small (last 1.5 weeks it took me) but fun little project I spent a lot of time on getting this right:

Press Ctrl+C to exit.
event=device_detected device=/dev/sda
event=job_started device=/dev/sda
event=job_finished device=/dev/sda result=detached

I.e. distinguishing IO error and detachment ;-) it does have the personal computer user story when you unmount etc. but instead sticks randomly coming and going so getting these right is at least useful when analysing any failure situations. jobs run on io_uring's and uevents through netlink socket bring like the other part of context information.

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 ;-)

Kernel Rust is like a different language (for better) ;-) It does not have any of the above issues.

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

@kidney with I added it together with sysfs discovery:

❯ build/lsiommu -h
Usage: build/lsiommu [-h]
Lists IOMMU groups and their associated PCI devices.
This version was compiled for sysfs discovery.

-h, --help Print help and exit

@kidney actually i somehow manage forgot to implement that. i'll add it back with sysfs support :-) thanks for notifying

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

@ge0rg and develop some utility modules like https://github.com/puavo-org/lsiommu/blob/master/down.c, https://github.com/puavo-org/lsiommu/blob/master/strbuf.c and https://github.com/puavo-org/lsiommu/blob/master/radix.c for the stuff that i'm working on.

@ge0rg it does not do whole alot that you could not do with trivial scripting. i had such a script for 10 years with bash and python but i wanted to consolidate that into C program to get a baseline that can be extended to do more complex things in future. and i needed to learn to use libudev properly for something more serious so this was a good exercise to test run it (my original script traversed sysfs).

@ge0rg in technical sense you can already do what my tool does with lspci -vmm, i.e. get IOMMU groups:

❯ lspci -vmm|head -25
Slot: 00:00.0
Class: Host bridge
Vendor: Intel Corporation
Device: 11th Gen Core Processor Host Bridge/DRAM Registers
SVendor: Hewlett-Packard Company
SDevice: 11th Gen Core Processor Host Bridge/DRAM Registers
Rev: 01
ProgIf: 00
IOMMUGroup: 3

Slot: 00:02.0
Class: VGA compatible controller
Vendor: Intel Corporation
Device: TigerLake-LP GT2 [Iris Xe Graphics]
SVendor: Hewlett-Packard Company
SDevice: TigerLake-LP GT2 [Iris Xe Graphics]
Rev: 01
ProgIf: 00
IOMMUGroup: 2

Slot: 00:04.0
Class: Signal processing controller
Vendor: Intel Corporation
Device: TigerLake-LP Dynamic Tuning Processor Participant
SVendor: Hewlett-Packard Company
# ...

But this is not very productive if you are interested IOMMU groups first and PCI devices second.

After a bit of tuning I ended up to "lsusb style" dump:

❯ lsiommu
Group 000 00:07.1 Class 060400: Vendor 8086 Device 9a25 [8086:9a25] (rev 01)
Group 001 00:07.0 Class 060400: Vendor 8086 Device 9a23 [8086:9a23] (rev 01)
Group 002 00:02.0 Class 030000: Vendor 8086 Device 9a49 [8086:9a49] (rev 01)
Group 003 00:00.0 Class 060000: Vendor 8086 Device 9a14 [8086:9a14] (rev 01)
Group 004 00:04.0 Class 118000: Vendor 8086 Device 9a03 [8086:9a03] (rev 01)
Group 005 00:0a.0 Class 118000: Vendor 8086 Device 9a0d [8086:9a0d] (rev 01)
Group 006 00:0d.0 Class 0c0330: Vendor 8086 Device 9a13 [8086:9a13] (rev 01)
Group 006 00:0d.2 Class 0c0340: Vendor 8086 Device 9a1b [8086:9a1b] (rev 01)
Group 007 00:0e.0 Class 010400: Vendor 8086 Device 9a0b [8086:9a0b] (rev 00)
Group 008 00:14.0 Class 0c0330: Vendor 8086 Device a0ed [8086:a0ed] (rev 20)
Group 008 00:14.2 Class 050000: Vendor 8086 Device a0ef [8086:a0ef] (rev 20)
Group 009 00:14.3 Class 028000: Vendor 8086 Device a0f0 [8086:a0f0] (rev 20)
Group 010 00:15.0 Class 0c8000: Vendor 8086 Device a0e8 [8086:a0e8] (rev 20)
Group 011 00:16.0 Class 078000: Vendor 8086 Device a0e0 [8086:a0e0] (rev 20)
Group 012 00:1d.0 Class 060400: Vendor 8086 Device a0b0 [8086:a0b0] (rev 20)
Group 013 00:1f.0 Class 060100: Vendor 8086 Device a082 [8086:a082] (rev 20)
Group 013 00:1f.3 Class 040100: Vendor 8086 Device a0c8 [8086:a0c8] (rev 20)
Group 013 00:1f.4 Class 0c0500: Vendor 8086 Device a0a3 [8086:a0a3] (rev 20)
Group 013 00:1f.5 Class 0c8000: Vendor 8086 Device a0a4 [8086:a0a4] (rev 20)
Group 014 55:00.0 Class 010802: Vendor 144d Device a808 [144d:a808] (rev 00)

I don't want to stringify classes or other elements right now because this output always fits the screen, which matters to me.

@kidney not whole a lot

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

fuck https://github.com/puavo-org/lsiommu/commit/23c7740709b5e288337dbe02853f897ee5eb07a0

i reworked PCI address representation which will allow to use radix sort for both cases:

https://github.com/puavo-org/lsiommu/commit/572ea9d86285f48afd0249dc32cea704e2d5512b

i guess it makes overall sense