For using #QEMU in #CI generating ephemeral #SSH key pair is one option but after playing for a while with that option I realised that you can create named pipes:

mkfifo tty.{in,out}

And then pass -serial pipe:tty to QEMU. After this commands can be emitted to tty.in and the output can be read from tty.out.

I think this a quite good strategy when having to orchestrate headless QEMU instances without any high-level infrastructure, such as libvirt.

I packed swtpm for the #QEMU build so it does not have to be installed to the system:

https://github.com/jarkkojs/tpmdd-buildroot-external

start-qemu.sh will automatically setup shenanigans so that swtpm will work as TPM emulation host for QEMU.

After build there’s three options:

1. TPM2 TIS/FIFO: output/build/images/start-qemu.sh
2. TPM2 TIS/CRB: output/build/images/start-qemu.sh --tpm-crb
3. TPM1 TIS/FIFO: output/build/images/start-qemu.sh --tpm1

Right, and neither QEMU needs to be installed to the host. I’m trying to sort of construct this in a way that it would become as CI friendly as possible so that this could be in addition used as a CI workload for keyutils.

#BuildRoot #linux #kernel #tpm

My new (WiP) orchestrator for building test image for testing my #kernel tree is fully implemented with GNU make:

# SPDX-License-Identifier: MIT

ROOT			:= $(dir $(abspath $(firstword $(MAKEFILE_LIST))))
BUILDROOT_VERSION	:= 2023.11
OUTPUT			:= $(ROOT)output
BUILDROOT_URL		:= https://buildroot.org/downloads/buildroot-$(BUILDROOT_VERSION).tar.gz
EXTERNAL_URL		:= https://github.com/jarkkojs/tpmdd-buildroot-external/tarball/main

define make-buildroot
	make -C "$(OUTPUT)/buildroot" BR2_EXTERNAL="$(OUTPUT)/external" O="$(OUTPUT)/build" $(1)
endef

define download-package
	mkdir -p $(2)
	curl -sL "$(1)" | tar -zxv -C "$(2)" --strip-components=1
endef

all: buildroot

.PHONY: buildroot
buildroot: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,all)

.PHONY: buildroot-menuconfig
buildroot-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,menuconfig)
	$(call make-buildroot,savedefconfig)

.PHONY: linux-menuconfig
linux-menuconfig: $(OUTPUT)/download-stamp
	$(call make-buildroot,tpmdd_qemu_x86_64_defconfig)
	$(call make-buildroot,linux-menuconfig)
	$(call make-buildroot,linux-savedefconfig)

$(OUTPUT)/download-stamp: 
	$(call download-package,"$(BUILDROOT_URL)","$(OUTPUT)/buildroot")
	$(call download-package,"$(EXTERNAL_URL)","$(OUTPUT)/external")
	touch $@

.PHONY: clean
clean:
	rm -rf "$(OUTPUT)"

It is pretty robust structure because I can e.g. easily add packages (like maybe host swtpm) in a robust manner to buildroot.

#buildroot #linux

To test latest linux-tpmdd changes:

git clone https://github.com/jarkkojs/test-tpmdd
cd test-tpmdd
make

Then:

1. TPM2 TIS/FIFO: output/images/start-qemu.sh --swtpm
2. TPM2 TIS/CRB: output/images/start-qemu.sh --swtpm --tpm-crb
3. TPM1 TIS/FIFO: output/images/start-qemu.sh --swtpm --tpm1

Tools for testing (more in future):

• keyutils for testing keyring and trusted keys
• /usr/lib/kselftests/run_selftests.sh

Requires swtpm to be installed (but not QEMU, it will build one).

#linux #kernel #buildroot

took sort of more productized approach by using `BR2_EXTERNAL` so that I don't have to touch #BuildRoot's Git history: https://github.com/jarkkojs/test-tpmdd

I'll focus on x86_64 first and then work on adding Raspberry Pi 3B+ support back.

https://github.com/jarkkojs/test-tpmdd

#linux #kernel

Work Hard. Play Hard.

Zuckerberg heading into 2024

What is a good strategy when having a C project and you'd want to start converting subportions of it to Rust? The project in question uses just plain makefiles and glibc.

Looking for some idiomatic patterns if such have been invented and documented.

#rustlang #posix

"easter eggs" in #Xfer #Serum and #SerumFX

Linus might be willing to drop support for i486-class machines[1] from the #Linux #kernel.

No, nobody asked for that directly; he brought that up in a discussion himself: https://lore.kernel.org/all/CAHk-%3DwhESMW2v0cd0Ye%2BAnV0Hp9j%2BMm4BO2xJo93eQcC1xghUA@mail.gmail.com/ #LinuxKernel

[1] and a couple of processors which _claimed_ to be Pentium class, but weren't

In my work (or more like home office) desktop I started to use #sway (#i3 #wayland replica). Works for that really well, would not put it to my casual/studio desktop tho (which is mac mini anyway). i.e. you can use it make your console like you had your power plant or something :-) my friend tuomo.wrote the original #ion3 window manager, which influenced this and few others back in the day.

more direct ion3 derivative also continues to live on as https://notionwm.net/ and i've heard that there is also wayland replica of this.

lol what #Trump #NFT cards. when the comedy writes itself https://www.youtube.com/watch?v=fBTmZHcjDgQ

Scumm Bar 3D technique explained and open-sourced! ⌨️🗒️📺

Apologies it took so long and thank you to everyone chasing me to make this follow-up ❤️‍🔥

RVX Projector:
https://github.com/mausimus/rvx-projector

#voxel #monkeyisland #retro #pixelart

so yasm vs. nasm? :-) confusing, i was aware only of latter and that's what i've been using in the past (not very recently, mostly just gas).

Do not know much about #oauth2 but I wonder if I could extract from #Thunderbird the login certificate and re-use that in #aerc?

#email

katsoin tyttöystävän kanssa #leijonanluola:n ekan jakson. OK, myönnetään se itse keksintö oli vähän mitä nyt oli mut se tilitys sen jälkeen kuinka rauta on niin vaikeeta, että ei sellaista bisnestä Suomeen. Thanks Nokia but no thanks ja sillein.

Sit tulee jotain lääkehourusen kuulosta hölinää kaarnan nuuhkimisesta ja metsässä sekoilusta. Ei mitään teknokraatteja ainakaan nämä puunhalaajaleijonat.

Tajuun kyl tod että ei tollaista keksintöä kukaan alaa rahoittaa, mut siis en yhtään ymmärtänyt sitä taantumuksellista läpän heittoa sen jälkeen.

Tervetuloa appi- ja konsulttisuomeen.

#leijonat #nokia #startup #slush #app #tieto #valueforlife

Mark your calendars: vger migration is being finalized this Thursday!

https://lore.kernel.org/linux-kernel/20231212-unselfish-real-myna-67e444@lemur/

aiemmin sanoin että en käytä #wolt:a eettisten syiden takia, mikä on totta.

toinen syy on se, että se alusta ei toimi. mulla on asunto #tampere:n ydinkeskustassa, mutta sen ulko-ovi ei ole rappukäytävässä. ne muutamat kerrat kun oon tyypannut, niin sitä saa olla lähikaduilla puhelimen kanssa etsimässä kuskia. woltilla on karttamerkintä, mutta ei se kyllä mitään tunnu auttavan.

myös #foodora:a kokeilin jossain vaiheessa, ruoka ei tullu lainkaan perille, ja ne ei maksanut rahoja takaisin, koska olin kuulemma ottanut ruoan vastaan :-)

eli vaikka haluaisin käyttää, niin en oo tarpeeksi vippi noiden asiakkaaksi i guess...

YES https://plogue.com/products/chipsynth-c64.html #commodore #c64 #sid

It is 2023 but for me #Github runners are new, flashy and exciting thing. I put some for my #zmodem2 crate ( basic CI tests).I discovered these functionalities for the first time in 2022 while at #Profian, and working on #Enarx.

I was thinking that I could start to mirror my kernel.org tree to GIthub just to run some CI but can you disable PR's completely? If not, then I think I pass . What about #Gitlab?

Have not used Gitlab that much David (Howells) just set me up access for keyutils repository so have to learn to use it more.

What has turned me away so far from Gitlab is that already Github is sometimes really feeling like someone was drilling a hole through my head and Gitlab on surface looks to have even more all kinds of weird controls and looks somewhat scary but perhaps the real truth is different than my prejudice :-)