Posted on May 25, 2024 by Felipe Aníbal
Last updated on June 24, 2024
In the previous post I shared some of the challenges we faced while contributing to the linux Kernel. Before coding we had a lot of work to do setting up the proper environment to build the Kernel. That involved launching virtual machines, writing configuration files and running series of commands to build the modules. After changing the code and building the Kernel, we still had work to do formatting the patch and writing the email to submit to the subsystem maintainers. It turns out that much of the work we did manually can be done automatically with bash scripts. When building new versions of the Kernel is something you do regularly these scripts can be extremely useful. In fact, many of the Kernel developers that we met during the classes showed us some of their own scripts.
Having noticed the usefulness of such scripts, Rodrigo Siqueira (former student at USP) began Kworkflow or simply KW, a open source software to help kernel developers in the process of developing the linux kernel. In this post I describe how Otávio Silva and I made a contribution to the KW.
When contributing to open source software the first step is always to understand the software. We did that by installing KW and using it to accomplish some of the tasks we had done manually before. After learning the basic workflow and the commands, we began looking for an open issue at the projects git repository to contribute to. That was a challenging part since the project maintainers didn't close most of the fixed issues. That meant we had to look at dozens of open issues and check one by one to see which ones were indeed open, and which ones should have been closed already. Thankfully we had in-person access to some of the project maintainers and directly talked to then to find an issue we could work on. We choose to implement a simple new feature to the drm command.
The drm subsystem (Direct Rendering Manager) is responsible for interfacing with GPU video cards. KW has a series of commands to help specifically with the development of this subsystems. One such command is kw drm --conn-available. This lists all connectors available in the target machine. The feature we chose to implement was to make that command more informative and not only list the available connectors but also show which ones were currently being used.
The change itself was simple. We changed the code to access the sys/class/drm directory for each connector and check under the "enabled" file to see if it was enabled. We then printed an asterisk after the name of the enabled connector. Besides the change to the command itself we updated the documentation and the tests to reflect the changes to the command. We ran the integration and unit tests and finally submitted the code with a pull request to the kw repository.
Our pull request passed through 5 reviews and had to be updated and sent again 5 times. In those reviews we ended up updating the coding style for the whole file, we optimized the way we searched for the "enabled" files for each card, and we implemented a slight change in the way the names of the connectors were displayed (to make the command even more informative). The whole process took a few weeks, but it pushed us to learn a lot as we got more familiar with git and github and learned to make our code more maintainable (adding comments, refactoring the tests and following the proper coding style). After 5 reviews our code was pull request was accepted and our code merged with the official repository.
This was my first experience contributing to an open source software other than the Kernel. It was a very good opportunity to see in practice what strategies can make the code more maintainable, like a good documentation, descriptive comments explaining coding choices and following a clean code style. It also showed us some things that make a open source project easier to contribute, like an active community and organized issue tracking (something that this project could perhaps improve for the future!). The maintainers were very patient and helped us a lot with the reviews and suggestions. Overall our contribution was small, nonetheless it was very rewarding to contribute to something that may be used by hundreds of people in the future! Hope we can apply the things we learned here in future projects.