... or actually totally unneeded given low amount of groups but it can be ;-)

derived radix sort from https://www.cubic.org/docs/radix.htm (because it is good fit for the purpose)

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

@andrew it's quite painful system to use https://en.wikipedia.org/wiki/Troff

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

first valgrind pass i tried also looked pretty decent:

==425020==
==425020== HEAP SUMMARY:
==425020==     in use at exit: 0 bytes in 0 blocks
==425020==   total heap usage: 2,143 allocs, 2,143 frees, 786,679 bytes allocated
==425020==
==425020== All heap blocks were freed -- no leaks are possible
==425020==
==425020== For lists of detected and suppressed errors, rerun with: -s
==425020== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

was a bit surprise tho :-)

❯ 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

Deps where "bookworm optimized", i.e. I used that debian version as the lowest common denominator for the deps.

#debian

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

@thomasmey i'm aware of this stuff but yeah i'm talking about something much more simple and stupid (see my respnoses) :-)

I even have developed this small function to my shell config number of years ago that pulls tag from any git repository to another that I've sometimes found convenient:

function git-fetch-tag
git fetch --no-tags "$argv[1]" "refs/tags/$argv[2]:refs/tags/$argv[2]"
end

(currrently a fish version of it :-) )

Also you might want to keep your account files for command-line tools in a different private repository even if it does not contain passwords (as it shouldn't but instead use pass). It still contains e.g., email addresses and stuff like that.

Without a special Git feature you need to fix the problem in your configuration. I.e copy the files from a clone, which is incovenient.

I explained myself badly.

Git as GIT_DIR and --git-dir for specifying location of the ".git".

What would be nice if there was also something like --git-dir-alias or similar for specifying non-standard name for that directory.

Then I could along the lines of

git clone <project URL>
cd <project>
export GIT_DIR_ALIAS=".git-private"
git init && git remote -add origin <private data URL> && git fetch origin && git reset --hard origin/main
unset GIT_DIR_ALIAS

It's not uncommon to initialize Git repositories to populated directories. E.g. that is how I clone my home directory skeleton on a new system:

git clone https://codeberg.org/jarkko/skeleton
git reset --hard origin/main

This is just extension to it. Home directories are great example use case also because then you could have separate Git repositories, if you want to isolate settings of a particular program but still have means to deploy them under the same root where they are cloned.

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

There is an alternative for Rocksmith, which also plays its '.RS files: https://tonelib.net/jam-overview.html

This not only fixes the issue macOS but there is also a native Linux version. Further, it happened to be 60% discount :-)

this motivates to work on my zmodem2 crate again (it is still more than a useful protocol in the modern world e.g., with FPGAs). i think i expand the test programs as utilities having tuis.

https://codeberg.org/jarkko/zmodem2

Cool, my PR for rust-hex was merged:

https://github.com/KokaKiwi/rust-hex/pull/83

It adds decode_in_slice() function, which decodes the hex string within the input buffer overwriting the contents. It is with ugly but still useful for e.g., fast and constrained protocol implementations.

Just came as surprise because the PR was made almost two years ago...

#rust #rustlang

I enjoyed responding this:

https://lore.kernel.org/linux-integrity/aGffUrDSjNH6w6rB@kernel.org/

Enjoyment did come like e.g, for "winning the argument". Instead it s fun to do this type of comparisons for the cause and effect of choices to the resulting binary :-) I did honestly did not know the correct answer beforehand.

Reviewing random day-by day patches can be boring. If I have some extra bandwidth this how I usually spice it up just a bit.

#linux #kernel #arm

@lkundrak lol i immediately decided to drop it

The fact that the issue is so trivial makes me doubtful of myself in this one:

https://github.com/himmelblau-idm/himmelblau/pull/592

#systemd #himmelblau