For a long time I’ve had this goal of getting into Linux Kernel development. After a lot of trial and error, and with the help of a friend of mine who agreed to mentor me in the process, I finally did it.
The change itself is not that interesting, you usually don’t want your first attempt at this to be something too complicated. There is enough to learn in terms of the development workflow and, specially, how to format and send patches the correct way.
There is already a lot of content on the internet on how to contribute, but what I found was that there are many different ways to do it and in the end it comes down to personal preference. I won’t try to cover everything I tried and will limit to describing what worked well in the end.
Building and Running
virtme-ng is a tool that simplifies the process of building the kernel and setting up a qemu virtualized environment to run it. virtme-ng will use a minimal kernel config to achieve fast build times.
To build a kernel, simply run:
vng -b
And to run it:
vng
The command above will put you into a qemu virtual machine with the newly built kernel. The system starts with an exact copy of your local filesystem and leverages CoW (copy-on-write) to avoid copies (and still prevent you from messing up the host).
Managing patches
One of the daunting things about Kernel development is the whole email based development process. This was very different than everything I’ve done before. Luckily, there is a tool to help with all this process (you can even get by without any text-based email client locally!).
b4 was initially developed to aid maintainers reviewing kernel patches but at this point it is also a powerful tool for any contributor that wants to send patches.
b4 prep -n my-patch will setup a branch on your git repository and a commit with a cover letter. You can now start working on your patch and adding new commits on top of this. Or if its a simple patch, a single commit with all the changes will do.
Once ready, you can use $ b4 prep --auto-to-cc which will add all the relevant maintainers to the list of recipients of your patch. You can then use $ b4 send to send the patch (I recommend using --reflect first to send it only to yourself).
As my patch was to be sent to net-next, I’ve used b4 prep --add-prefixes net-next to include that on the patch. My understanding is that this will vary subsystem by subsystem and there is usually a Wiki that will explain how you should do it (similar to the netdev one).
After your send a patch, if you make new commits or changes to existing commits it will automatically create a new version of your patch and, once ready, you can submit v2. b4 provides an email relay that can be used if you don’t have local email client setup on your box, although you might want to set mutt or some equivalent tool in order to interact with the maintainers.
Kernel Selftests
My first patch was to add a new selftest to netconsole. Selftests are tests written on various different languages (c, python and bash) and they are used to validate different kernel features. Netconsole selftests required Kernels to be build with specific config options and it was fairly easy to get that setup with vng since the config snipped is provided in the selftest directory.:
vng -b --config tools/testing/selftests/drivers/net/config
And to run the tests:
vng -e 'sudo make -C tools/testing/kselftests TARGETS=drivers/net run_tests'
This made the workflow very fast and easy!