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.