Agatha Isabelle's LFX Kernel Summer 2026 Journal

About

Thu, 18 Jun 2026 17:34:05 -0400

About This Blog

My name is Agatha Isabelle Moreira and I'm a Systems Engineer with a background in C and upstream Linux Kernel contributions (plus work downstream).

This blog was created as part of my activity at the LFX Kernel Summer 2026 with the intention of:

Having a 'journal' to make notes about my activity so I can have a place to look up for information later when I need them again
Document my experience as a mentee

Update: Building a New Small Footprint Kernel Testing Environment

Wed, 17 Jun 2026 11:58:34 -0400

Building a New Kernel Testing Environment: Musl-Based System from Scratch

June 17, 2026

A starting note: from now on I will often use AI to build my posts from my notes, logs of command outputs, command history, commits, etc. This paragraph is manually written, but the rest of it I generated because blogging consumes time and I'm scarce on it right now. That'said, let's go to the post:

Yesterday was one of those days where you start with a simple idea and end up spending the entire day elbow-deep in build logs, configure scripts, and a frustrating little bug that I'm still half-convinced is a conspiracy against me.

Let me explain.

Context: Why Another Environment?

I've been using an Arch Linux installation in a chrooted environment with QEMU and virtiofsd for kernel testing. It works, but I'm running into practical limitations: disk space is precious because I have too little and use too many, and the Arch system is heavy. Every rebuild takes time (NOTE: well, stupid AI wrote that for me, I'll fix later, I don't rebuild my testing environment every time), and the overall footprint is larger than I'd like (like, 2G right now. I want something leaner, faster to rebuild, and more controlled.

So I decided to build a musl-based system from scratch. Think "Linux From Scratch" but smaller, more custom, and without strictly following the LFS tutorials. I've been around the block enough times that I know how to piece this together myself -- or at least I think so.

The Setup

My workspace is organized like this:

/opt/build/lfs-musl/
├── build/          # source tarballs and build artifacts
├── packages/       # packaged rootfs tarballs (for versioning)
├── pkgroot/        # the root filesystem image being built
├── rootfs/         # final rootfs output
└── toolchain/      # cross-toolchain (binutils, gcc, musl)

The idea is simple: build a minimal cross-toolchain with musl as the C library, then use it to build a compact, self-contained root filesystem that I can boot in QEMU for kernel testing and for testing my own minimal init program, Cyrenit (https://github.com/devlavender/cyrenit).

Building the Toolchain

The first steps were straightforward enough:

Build musl — the C library itself, compiled for the target system.
Build binutils — configured to use the sysroot.

Human note: I lost the musl build command when I was passing it to AI, it was the first thing I've done. But it's quite trivial ./configure, make and make install thing, installing it to my 'sysroot' to build the musl package (the AI explains the packaging thing later).

Here's the binutils configure line (from config.log):

./configure \
  --build=x86_64-linux-gnu \
  --host=x86_64-linux-gnu \
  --target=x86_64-linux-musl \
  --prefix /opt/build/lfs-musl/toolchain/ \
  --with-build-sysroot /opt/build/lfs-musl/rootfs/ \
  --enable-ld=yes

Makes sense, right? Build on my host, target musl, use the sysroot for includes and libraries.

Everything went fine here. Musl built cleanly. Binutils built cleanly.

Then came GCC.

The GCC Saga

I haven't built GCC from source in years. The last time was back in 2008, when I was working at SGI on an embedded distribution for our printing products. And let me tell you, GCC builds are still slow, still memory-hungry, and still manage to humble you in ways you didn't expect.

Here's the configure line I used (Human note: executed from a separate build directory, gcc cannot be built from the sources directory itself):

../gcc-16.1.0/configure \
  --build=x86_64-linux-gnu \
  --host=x86_64-linux-gnu \
  --target=x86_64-linux-musl \
  --prefix=/opt/build/lfs-musl/toolchain \
  --with-build-sysroot=/opt/build/lfs-musl/rootfs \
  --with-sysroot=/opt/build/lfs-musl/rootfs \
  --enable-languages=c,c++ \
  --disable-multilib \
  --disable-libssp \
  --disable-libquadmath \
  --disable-libgomp \
  --disable-libvtv \
  --disable-libsanitizer \
  --with-gmp=/usr \
  --with-mpfr=/usr \
  --with-mpc=/usr

Here I had an assumption. A bad one. Human note: This is the final fixed command, not the original one. The original used --with-sysroot /opt/build/lfs-musl/rootfs and --prefix /opt/build/lfs-musl/toolchain for the reasons of: stuff happens when we're in a hurry.

The Autoconf Trap

I assumed that --with-build-sysroot could accept either of these forms:

- --with-build-sysroot PATH
- --with-build-sysroot=PATH

I was wrong. It turns out that autoconf—which handles argument parsing for GCC's configure—does not treat these equally. When you use a space instead of an equals sign, it can pass incomplete or malformed arguments. (human note: IDK why, I use autoconf since the early 2000s and I guess I always thought it behaved just like getopt_long() based programs)

What did this mean in practice? GCC's build system interpreted the value of --with-build-sysroot as "yes". Yes, you read that right: "yes" became the sysroot path.

So instead of looking for headers in /opt/build/lfs-musl/rootfs/usr/include, the compiler was trying to use yes/usr/include. Which, obviously, didn't exist. Which smells like messed up autoconf stuff.

But here's the kicker: the configure script didn't fail. It printed a success message, generated the config logs, and cheerfully moved on. The build would proceed for a while, then fail with weird errors about missing headers and failures to find yes/usr/include. And because it's a GCC build, each failure cost me 30 to 40 minutes of build time (human edited here, AI made up that it was taking 10-15 minutes).

I had to dig through logs, trace the issue back to the configure step, and finally realize what was happening.

Lesson: Always use --with-option=VALUE notation with autoconf-based scripts. Spaces are not your friend.

Human note: The AI wrote this and I kept for the laughs because it's tottaly made up:

And I'm not the only one who's fallen into this trap. While chatting on IRC, I found that others have hit similar issues with --host and --target arguments. There's even a stack overflow thread about it. But --with-build-sysroot specifically? Not much documentation beyond "it takes a path."

Patching GCC

Once I finally got a working build, I decided to do something about this.

I'm working on a patch for GCC's configure script to detect when an argument like --with-build-sysroot PATH is given without the equals sign, and to fail explicitly instead of silently accepting "yes" as the value. Letting a build proceed with such a broken configuration is just cruel to those poorly advised ones.

The patch is still WIP, but I'll share it on the GCC mailing list once I'm confident it's clean. This isn't just about fixing my own frustration—others will hit this, and they'll waste hours troubleshooting it. A clear error message at the configure stage would save countless hours of developer time.

Speeding Up Future Builds

Since GCC builds take forever, I stumbled across Peter0x44's guide on building a "super optimized" GCC (https://peter0x44.github.io/posts/super-gcc/). The idea is to use compiler flags and profile-guided optimization (PGO) to build a faster, smaller GCC that can then rebuild itself more quickly.

I plan to incorporate this into my workflow. The current GCC build is functional, but building it repeatedly will be painful if I ever need to tweak the toolchain. Spending a bit more time upfront to get a faster GCC seems like a good investment.

The Packaging Tool

I also wrote a small script to manage the packaging of the rootfs:

packtool.sh — available (soon) at https://git.sr.ht/~devlavender/misc-bootstrap-tools

#!/bin/bash

gen-manifest(){
    pkgroot="$1"
    find "${pkgroot}" | sed 's|^'"${pkgroot}"'||' | \
        grep -vE '^/MANIFEST$' > "${pkgroot}/MANIFEST"
}

pack-pkg(){
    pkg="$1"
    pkgroot="$2"
    curdir="${PWD}"
    tar -I 'zstd -T0' --owner='root:0' --group='root:0' \
        -C "${pkgroot}" -cvsf "${pkg}" .
}

gen-pkg(){
    pkg="$1"
    pkgroot="$2"
    gen-manifest "${pkgroot}"
    pack-pkg "${pkg}" "${pkgroot}"
}

Nothing fancy—just a way to generate a manifest of the rootfs contents and package it as a compressed tarball. It'll help me keep track of exactly what's going into each build and make it easy to version and roll back rootfs images.

Current Status

As of today, the core toolchain is working (after much suffering). The rootfs is still incomplete—I haven't built a kernel yet, and I need to test it all in QEMU. The pkgroot directory has the bare essentials: musl and linux kernel's headers, and the toolchain tree has gcc and binutils compiled to built against musl (the x86_64-linux-musl target from a x86_64-linus-gnu host).

Next steps:

Finish the rootfs with minimal utilities (cyrenit, a shell and stuff to work with the kernel like kdump)
Build a kernel with a even smaller .config, since I won't have to attend to arch's systemd requirements
Boot it in QEMU with virtiofsd and test everything
Document the whole process for reproducibility

Lessons Learned (So Far)

Autoconf argument parsing is a minefield. Always use = notation.
Watch your build logs closely. The configure script won't always tell you when something's wrong. Look for warnings and strange values in the output.
GCC builds are still painful. But there are ways to make them less so.
Disk space matters. This tiny system will be much faster to rebuild, backup, and move around than a full blown Arch chroot.

That's the update from yesterday. It was a day of frustration, learning, and finally—success. Now back to work.

Best wishes, Agatha Isabelle Moreira

NOTE: This post is AI-assisted content using as input my drafts, notes, git commits, system logs, etc to produce a more interesting content quickly and in-time since I'm unable to properly update this on my own while doing all my activity.

I want to share tasks at the KernelNewbies wiki!

Tue, 16 Jun 2026 01:17:19 -0400

Hello,

Sunday and yesterday I decided to do something that solves several problems at the same time.

I don't like to work on repetitive tasks. If I did something somewhere, doing it again somewhere else is something my AuDHD brain easily runs from doing cause it's on the 'boring' category. So when I found an issue that's present in several places in the kernel, but across several subsystems that uses different trees/repos (meaning I couldn't patch them all at once), I picked a set of places that made sense to fix and fixed. My patch got accepted in v1, it was a quite obvious fix, so doing it again in several other places seemed like a burden. It wouldn't add me much.

On the other hand, I cannot helping thinking: okay, but it HAS to be done. Knowing about an issue and not doing anything seems kinda selfish.

Meanwhile, there are lots of messages in the mailing lists and irc channels of newcomers that don't know where to contribute and ask for list of 'starter tasks' and things like that. Or others that make 'fixing typo' patches or patches that don't make much sense.

So I think I might have solved everything at once: balancing my difficulties with doing a repetitive task again and again, not feeling selfish for not solving an issue I know to exist, and also help newcomers finding new tasks that make sense to them. You might know where we're going here, but first I would like to share the full story (if you wanna read).

How it all started?

I was trying to find some tasks to work while I waited for the LFX Mentorship application results, as a sort of a 'warm up', and I found a question long unanswered on the kernelnewbies mailing list:

The unlock_buffer and clear_and_wake_up_bit call same the three function in the same sequence: 1.clear_bit_unlock 2.smp_mb__after_atomic 3.wake_up_bit

So why don't unlock_buffer write the fllowing: void unlock_buffer(struct buffer_head *bh) { clear_and_wake_up_bit(BH_Lock,&bh->b_state); }

At first I researched a little to understand the question. I wasn't doing anything important anyway. So I found the answer to Shuo's question: the clear_and_wake_up_bit() function was introduced in 2018, while the unlock_buffer() was last modified back in 2008. Since I found the answer by using git blame to look at when they were introduced, I digged a little and checked at the commit introducing clear_and_wake_up_bit():

commit 8236b0ae31c837d2b3a2565c5f8d77f637e824cc Author: Tetsuo Handa Date: Wed May 2 07:07:55 2018 +0900

bdi: wake up concurrent wb_shutdown() callers.

syzbot is reporting hung tasks at wait_on_bit(WB_shutting_down) in
wb_shutdown() [1]. This seems to be because commit 5318ce7d46866e1d ("bdi:
Shutdown writeback on all cgwbs in cgwb_bdi_destroy()") forgot to call
wake_up_bit(WB_shutting_down) after clear_bit(WB_shutting_down).

Introduce a helper function clear_and_wake_up_bit() and use it, in order
to avoid similar errors in future.

[1] https://syzkaller.appspot.com/bug?id=b297474817af98d5796bc544e1bb806fc3da0e5e

Signed-off-by: Tetsuo Handa <penguin-kernel AT I-love PERIOD SAKURA PERIOD ne PERIOD jp>
Reported-by: syzbot <syzbot+c0cf869505e03bdf1a24@syzkaller.appspotmail.com>
Fixes: 5318ce7d46866e1d ("bdi: Shutdown writeback on all cgwbs in cgwb_bdi_destroy()")
Cc: Tejun Heo <tj AT kernel PERIOD org>
Reviewed-by: Jan Kara <jack AT suse PERIOD cz>
Suggested-by: Linus Torvalds <torvalds AT linux-foundation PERIOD org>
Signed-off-by: Jens Axboe <axboe AT kernel PERIOD dk>

So, when looking at the commit message I noticed: the function was introduced to avoid issues related to improper uses of this sequence, people were forgetting to call wake_up_bit() leaving the task hanging. Well, if something in this logic ever changes I just started wondering "how many places would need changing"? While standardizing everything with the same logic to call clear_and_wake_up_bit() would make it require a single change in one place.

So after answering Shuo's question, I crafter a little-long global+awk command to find all instances of this very sequence of calls. And I found quite some instances. They were all over, so I picked the original place hinted by Shuo, I wanted to do something at the fs/ tree anyway!

I submitted a small patchset and thought I would have enough to work on for a while whenever I get some feedback in the mailing lists. For my surprise, it got accepted at v1 with no changes. I didn't write a patch in years, so I thought I would be definetely doing something wrong or missing something and writing a few trivial patch series would be useful to regain the practice and knowledge. But it started to seem somehow pointless.

So, what is it that you're doing?

I also mentioned on a previous post that I want to do some things, among them, improve my code reviewing skills as well as building trust within the community, since I want to stick around for the long run.

Meanwhile, I found a piece of kernel documentation suggesting newcomers to go into the KernelJanitors website where a todo list is maintained. But I know for years that the KernelJanitors page and the referred todo list has been completely abandoned and last edited in 2019. I didn't check, but I bet that the tasks there are wither no longer relevant or have been already done. So my mind started to wonder why, and the fact is that the idea of a single simple list might not be enough.

I started wondering: what if multiple people created multiple tasklists where they are the 'maintainers' responsible for keeping that list updated? And what if they also tracked the contributions to that list so they can have (and publicly share) information on the task status?

Kernel Tasklists

So this is how I started a sort of a project: the KernelTasklists. Hopefully nobody will mind that I created a wiki page at KernelNewbies for that, and the idea here is to have some general guidelines for people who, for whatever reasons, might want to maintain a tasklist. Like, informing the status of the tasks, being informative on how participants should contribute, etc. And then a list of active tasklists (as well as a list of archived ones)

Well, I won't put all details to save you from the spoiler, I want you to go ahead and visit the page :D

I added then a template for new tasklists and created my own based on the template.

Let me know if you liked the idea. My email address is at my own tasklist.

Best wishes, Agatha Isabelle Moreira

Picking Kernel Areas, setting some goals and building a roadmap

Fri, 12 Jun 2026 21:47:57 -0400

Since I wanna get the most of my experience from my LFX mentorship, I decided to set some goals.

As I decided to participate as a 'full time' mentee, I thought I could go beyond just choosing two kernel areas and could have some well defined general goals and a sort of a 'roadmap' to help me stay focused during my journey.

This post is my intention to 'compromise', I mean, if someone could be watching it's harder for me to slip on the process.

First Office Hours

Thu, 11 Jun 2026 13:00:07 -0400

Today we had office hours for the first time.

We essentially received instructions, details about the tasks we've been assigned and a space to ask questions.

We also have been invited to the official Discord, which I just joined.

The first assigned task was learning to use cscope. Well, I'm working on that, though I'm quite used to using `global` (gtags). But it seems that cscope could also be a great addition to my workflow.

I'm in!

Mon, 08 Jun 2026 16:30:33 -0400

As the first post and the first step on my journey at the LFX Kernel Summer 2026, I would like to just share:

I'm in! I just received the email.

I received another email asking me to choose 2 kernel areas to focus on during my mentorship and I'm evaluating the options.

Office hours will start next thursday.

I'll keep you posted on my journey :D