Marcus Folkesson

Embedded Linux Artist

Mutex guards in the Linux kernel

Mutex guards in the Linux kernel I found an interresting thread [1] while searching my inbox for something completely unrelated. Peter Zijistra has written a few cleanup functions that where introduced in v6.4 with this commit: commit 54da6a0924311c7cf5015533991e44fb8eb12773 Author: Peter Zijlstra <peterz@infradead.org> Date: Fri May 26 12:23:48 2023 +0200 locking: Introduce __cleanup() based infrastructure Use __attribute__((__cleanup__(func))) to build: - simple auto-release pointers using __free() - 'classes' with constructor and destructor semantics for scope-based resource management. - lock guards based on the above classes. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> It adds functionality to "guard" locks. The guard wraps the lock, takes ownership of the given mutex and release it as soon the guard leaves the scope. In other words - no more forgotten locks due to early exits.

Test packages in Buildroot

Test packages in Buildroot When writing packages for Buildroot there are several conditions that you have to test your package against. This includes different toolchains, architectures, C-libraries, thread-implementations and more. To help you with that, Buildroot provides the utils/test-pkg script. Nothing describes the script better than its own help text [1]: test-pkg: test-build a package against various toolchains and architectures The supplied config snippet is appended to each toolchain config, the resulting configuration is checked to ensure it still contains all options specified in the snippet; if any is missing, the build is skipped, on the assumption that the package under test requires a toolchain or architecture feature that is missing. In case failures are noticed, you can fix the package and just re-run the same command again; it will re-run the test where it failed. If you did specify a package (with -p), the package build dir will be removed first. The list of toolchains is retrieved from support/config-fragments/autobuild/toolchain-configs.csv. Only the external toolchains are tried, because building a Buildroot toolchain would take too long. An alternative toolchains CSV file can be specified with the -t option. This file should have lines consisting of the path to the toolchain config fragment and the required host architecture, separated by a comma. The config fragments should contain only the toolchain and architecture settings. By default, a useful subset of toolchains is tested. If needed, all toolchains can be tested (-a), an arbitrary number of toolchains (-n in order, -r for random). Hands on In these examples I'm going to build the CRIU package that i recently worked on.

TIL - docker scratch image

TIL - Docker scratch image TIL, Today I Learned, is more of a "I just figured this out: here are my notes, you may find them useful too" rather than a full blog post The scratch image is the smallest possible image for docker. It does not contain any libraries nor other executables. It is simply a new, fresh and empty setup of namespaces. The FROM scratch line is even a no-op [1] in the Dockerfile, which results in that it will not create an extra layer in you image. Example of a Dockerfile:

Git version in cmake

Git version in CMake All applications have versions. The version should somehow be exposed in the application to make it possible to determine which application we are actually running. I've seen a plenty of variants on how this is achieved, some are good and some are really bad. Since it's such a common thing, I thought I'd show how I usually do it. I use to let CMake determine the version based on git describe and tags, the benefit's that it is part of the build process (i.e no extra step on the build server - I've seen it all...), and you will get right version information also for local builds.

TIL - sort in vim

TIL - Sort in VIM TIL, Today I Learned, is more of a "I just figured this out: here are my notes, you may find them useful too" rather than a full blog post After 15+ years of daily VIM usage I just discovered the :sort function. Quite embarassing. It is also possible to sort in revese ( :sort!) and remove duplicate lines ( :sort u). cover

Burn eFuses for MAC address on iMX8MP

Burn eFuses for MAC address on iMX8MP The iMX (iMX6, iMX7, iMX8) has a similiar OCOTP (On-Chip One Time Programmable) module that store, for example the MAC addresses for the internal ethernet controllers. The reference manual is not clear either on the byte order or which bytes belong to which MAC address when there are several. In fact, I had to look at the U-boot implementation [1] to know for sure how these fuses is used: cover

Loopback with two (physical) ethernet interfaces

Loopback with two (physical) ethernet interfaces Imagine that you have an embedded device with two physical ethernet ports. You want to verify the functionality of both these ports in the manufacturing process, so you connect an ethernet cable between the ports, setup IP addresses and now what? As Linux (actually the default network namespace) is aware of the both adapters and their IP/MAC-addresses, the system see no reason to send any traffic out. Instead, Linux will loop all traffic between the interfaces internally. cover

TIL - notmuch-lore

TIL - notmuch-lore TIL, Today I Learned, is more of a "I just figured this out: here are my notes, you may find them useful too" rather than a full blog post Notmuch [1] is an mail indexer and is a great tool to search in high-volume mailboxes (e.g. mailing lists). Being subscribed to all these mailing lists and retreiving all mails over IMAP daily could be quite annoying and harm your mail quota.

kas-container and QEMU

kas-container and QEMU KAS KAS [1] is a setup tool for bitbake based projects such as Yocto. There are many similiar alternatives out there and I've tried most of them, but my absolute favorite is KAS. In order to use KAS, you have to setup a YAML file to contain information about your machine, distribution, meta layers and local configuration. Here is a small example configuration copied from the KAS documentation: cover

TIL - git man-pages

TIL - git man-pages TIL, Today I Learned, is more of a "I just figured this out: here are my notes, you may find them useful too" rather than a full blog post I'm a big user of man-pages. Today I found a set of pages that I've not noticed before when I was reading man git: SEE ALSO gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcore-tutorial(7), gitcli(7), The Git User’s Manual[1], gitworkflows(7) Especially