After some experimentation it is best the define boards in this context as fairly self-contained packages to the specific test devices at hand and not have anything shared e.g. by CPU architecture even at the cost of some redundancy:

$ tree
.
├── Config.in
├── LICENSE
├── board
│   └── tpmdd_qemu_x86_64
│       ├── linux.config
│       ├── post-build.sh
│       ├── post-image.sh
│       └── start-qemu.sh.in
├── configs
│   └── tpmdd_qemu_x86_64_defconfig
├── external.desc
└── external.mk

4 directories, 9 files

E.g. similarly I’ll add tpmdd_raspberrypi3b target and so forth. For instance, I would not share post-image.sh and similar scripts between boards even if they were 1:1. It kills robustness.

The orchestrator itself has a flat repository:

$ tree
.
├── LICENSE
├── Makefile
└── README.md

I licensed external with GPL2 for the sake of upstream compatibility and orchestrator with MIT. This is overally pretty usable structure to use Buildroot.

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

@monsieuricon lot to digest, i did read it couple of times yesterday but really have to digest before responding. one constraint which should probably be set that it should be adaptable somehow to gitlab later on (not meaning that it must adapt right now but make sure that it is doable).

Work Hard. Play Hard.

@boxdot hey thanks! it does look promising 🙂

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

@vbabka do no get threat scenario but this is luckily quite functional extension for TB to write emails: https://github.com/Frederick888/external-editor-revived. There's external program in addition to extension but it is easy to setup. If you launch it without parameters it will tell you where to place a simple js file, of which contents it also outputs and after that TB takes care of launching it when it needs it

With email the threat scenario is mostly emails themselves and I cannot 100% guarantee that I do not fall on phishing unless I use text based email client :-)

And you can easily use it for generating extra wave cycles for saw too...

meaning that the day has come that i can finally fully capture VB-1 :-) people still use VB-1 a lot. it is sort of 303 of vst's. crappiest bass emulation ever but has sort of its own color. one of the first vsts ever released.

"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

@mkelly Yes, exactly. It sort of makes the hardware fit for the exact purpose you are using it :-)

@vbabka it is corporate 365 with all sorts of things blocked that usually work. No app passwords, no EWS, apparently they check client ID/password for TB because e.g. Evolution does not work.

I like to have also one Mac at home. It is pretty good for comparative testing e.g. with syscalls and also compiling ARM kernels (and testing them without having to use SBC's). To add, I don't want to focus on configuration when I make music and Linux is anyway my construction site. Nobody wants to spend 247 at work I guess :-)

I even had one Windows machine at some point but it required more maintaining than my other machines, NAS, network router etc. added together so I gave up on that... And Windows has also worst audio stack of the industry: the native one is pure garbage so there is proprietary ASIO stack that everyone uses from Steinberg, which results a trainwreck system overally.

Why people say that Linux audio sucks had nothing to do with kernel, it was just that low-latency audio was not well supported up until the uncrowned genius of multimedia Wim Taymans fixed the issue with Pipewire. Today in kernel/middleware level has hands down the best audio stack that there exists. I mean even in macOS you have to install 3rd party proprietary product called Loopback to be able to route audio like you can do with Pipewire.

this is more like workflow optimization than being geeky :-) pretty much same tools every single day and probably many years to come and dedicated computer for work.... also it is nice that if you ramp up a new system i can also deploy my desktop configuration along with other dotfiles fast.

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.

@rjzak i gave my RTX to my daughter so that she can play some new harry potter game :-)