Well, after spending the last few months studying and contributing to kworkflow as part of Google Summer of Code 2024 under the Linux Foundation, it’s time to catalog all the contributions made during this period. I can confidently say that this experience has been extremely enriching and has significantly advanced my development skills.

The kw build command is a versatile tool that encompasses everything related to building and managing Linux kernel images. It supports various options, such as displaying build information, invoking kernel menuconfig, enabling ccache, adjusting CPU usage during compilation, saving logs, and using the LLVM toolchain. Additionally, it provides options for cleaning the build environment, customizing CFLAGS, and compiling specific commits. The command also offers alert notifications and verbose mode for detailed debugging information.

kw-ssh is a feature in kworkflow that simplifies remote access to machines via SSH. It allows you to execute commands or bash scripts on a remote machine easily. Additionally, this feature supports file and directory transfer between local and remote machines.

Integration tests are designed to verify that different modules of a system work together as expected. They ensure that the interaction between components occurs seamlessly and that the system functions correctly as a whole.

In the final moments of the MiniDebconf in Belo Horizonte that I attended back in April, as I was heading to the airport to go back home, a notification popped up on my phone: I had been accepted into Google Summer of Code 2024. It was a surreal and incredibly exciting moment.

In my GSoC23 project, I had to understand the ins and outs of the lore API. By its API, I specifically mean the way requests to https://lore.kernel.org are responded, in other words, the syntax and semantics of requesting data stored in the lore archives, be it patches or available lists.

My GSoC23 journey, which I introduced in a previous post, is almost over. It really doesn’t feel like 16 weeks have passed, but I can say that, in this period, I have learned a lot and grown as a developer.

My GSoC23 project (which I talked about in a previous post) is about implementing a feature in kw that serves as a hub for the public mailing lists archived on https://lore.kernel.org, with a focus on patch-reviewing. The feature is called kw patch-hub and I will talk about what are the lore archives and its API in a later post, but in this post, I’m going to describe the Finite-State Machine model used on this feature.

Around May, I had the opportunity of helping to introduce a Database Management System (DBMS) to a project that used a file-based database. The DBMS was SQLite3 and the project was kw. This post describes my experience.

Being a somewhat new user of Zsh - made the transition from Bash around 2 months ago - I never thought I would have to learn about its completion system or how to write my own custom completion functions so soon.

I usually have my dev system and a test machine to validate my changes for developing to the Linux kernel. I also keep my config files and use them every time for my test systems. Nevertheless, I recently had to get a different test system (but very similar), and I created a new config file based on the ones that I already had; everything worked as usual, except for this error during the boot:

Since January, I have been refactoring and improving the deploy code in order to make it easy to add other platforms. Introducing Raspberry Pi support was a great study case to find the weak points in the deploy and make it more generic. As a result, I finally have a PR that enables Raspberry PI deploy and modularizes the deploy code. Check it at:

When I started contributing to Linux Kernel, one of my favorite tasks for learning more about the kernel was following the public mailing list of the subsystem that I was interested in. A few months after I started contributing to the kernel, I became a maintainer and had to follow patches related to the driver that I was maintaining. A few weeks ago, I also became one of the maintainers of the display component under the amdgpu driver. Yeah… I am aware that I’m doing poor work as a maintainer, which I blame the lack of structure in my review flow. Don’t get me wrong, I was trying… for example, I set up my neomutt to help me with that, but unfortunately, I could not use it anymore due to external forces, which broke my already inefficient review process. Anyway, I’m uncomfortable about that since I want to be a better maintainer, but I realize that I need to fix my workflow.

For a long time, I’m aiming to expand kw to provide good support for non-x86 machines. As part of this effort, I enabled kw deploy to work with an ARM target system that resembles x86, and fortunately, it works really well. However, as a DIY enthusiast, I always wanted to enable kw to deploy custom kernels to Raspberry pi, but I had the following obstacles:

For a long time, I have been considering creating a blog for the kworflow project where we can have posts that are not suitable to the standard documentation. I had this desire because sometimes, when I was working on some issues, I took some time to appraise some exciting topics related to Bash or Linux kernel that was worth publicly sharing. However, I utterly want something informal and with a low overhead to maintain. After asses my options, I decided to use a straightforward Jekyll template with trivial automation associated with the main branch.