LIBRENEITOR

Linux Kernel Patches - Eudyptula Task 3

Mon, Jul 8, 2019

The basic of the creation of a Linux patch

The task 3 of the Eudyptula Challenge.

Part 1

The first item instructs us to: “modify the Makefile to and modify the EXTRAVERSION field. Do this in a way that the running kernel has the characters -eudyptula in the version string.”

I won’t modify the Makefile, I shouldn’t do that. I can modify the CONFIG_LOCALVERSION variable inside .config for that, in much more elegant way.

CONFIG_LOCALVERSION="eudyptula"

So, after booting the kernel with that option, I got the expected result:

/ # uname -r
5.2.0-rc7eudyptula

I know I forgot the - before the name, but I won’t recompile the kernel and wait 1hr+ just for an stupid -.

Part 2

The next step ask us to create patch that is acceptable for merging in the kernel. And that is why we need to read Documentation/process/submitting-patches.rst first. You need to read the whole document believe me, you will need it later. Or at least read it until you understand the following image.

The second part of this challenge really wants us to understand how we should interact with the mailing list when we are going to submit a patch. In other words, we are learning to make a type of Github Pull Request, in the linux kernel.

But before you can even send an email with your patch you need to know how to actually send the email. Yehaa, you can’t use GMail or Yahoo or any other type of web emails. You need to read Documentation/process/email-clients.rst. In the documentation you will find many clients and how to configure them to send patches. But I found that Mutt or NeoMutt is the most used mail client for the kernel development community. A freaking text based email client, incredible. So not only you will need to know how to create a patch but also how to configure and use the mutt client. I think that even if this is necessary is very annoying.

Now, after reading and configuring everything, I believe is time to create a simple patch. Lets modify the Makefile as originally requested by the task and create a patch.

$ git commit -m "change EXTRAVERSION as described in Eudyptula Task 3" -s
$ git format-patch HEAD~
0001-change-EXTRAVERSION-as-described-in-Eudyptula-Task-3.patch
$ cat 0001-change-EXTRAVERSION-as-described-in-Eudyptula-Task-3.patch 
From 3e16023ac929ded64ddede0fc4f987344aef5ddb Mon Sep 17 00:00:00 2001
From: Hernan Ezequiel Di Giorgi <hi@libreneitor.com>
Date: Mon, 8 Jul 2019 16:32:08 -0300
Subject: [PATCH] change EXTRAVERSION as described in Eudyptula Task 3

Signed-off-by: Hernan Ezequiel Di Giorgi <hi@libreneitor.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index fabc127d1..128c59c4c 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
 VERSION = 5
 PATCHLEVEL = 2
 SUBLEVEL = 0
-EXTRAVERSION = -rc7
+EXTRAVERSION = -the_new_extra-
 NAME = Bobtail Squid
 
 # *DOCUMENTATION*
-- 
2.20.1

I commited with a message as described in the documentation: “Describe your changes in imperative mood, e.g. “make xyzzy do frotz” instead of “[This patch] makes xyzzy do frotz” or “[I] changed xyzzy to do frotz”, as if you are giving orders to the codebase to change its behaviour.”

Also, I used the -s(--signoff) options while creating the commit: “Add Signed-off-by line by the committer at the end of the commit log message. The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin.”

Then if we wanted to send this .path with mutt we could:

mutt -H 0001-change-EXTRAVERSION-as-described-in-Eudyptula-Task-3.patch

Until this point is everything fine, but to whom should we send this email? ./scripts/get_maintainer.pl has the answer.

./scripts/get_maintainer.pl 0001-change-EXTRAVERSION-as-described-in-Eudyptula-Task-3.patch 
Masahiro Yamada <yamada.masahiro@socionext.com> (maintainer:KERNEL BUILD + files below scripts/ (unless mai...)
Michal Marek <michal.lkml@markovi.net> (maintainer:KERNEL BUILD + files below scripts/ (unless mai...)
linux-kbuild@vger.kernel.org (open list:KERNEL BUILD + files below scripts/ (unless mai...)
linux-kernel@vger.kernel.org (open list)

Knowing how we can get all the maintainers associated to a file, we can simply call mutt with those emails as arguments:

mutt -H [patch] -c $(./scripts/get_maintainer.pl [patch]) 

Other resources