<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>Bryan Brattlof - Eudyptula Challenge</title><link href="https://0x42.sh/" rel="alternate"/><link href="https://0x42.sh/feeds/eudyptula-challenge.atom.xml" rel="self"/><id>https://0x42.sh/</id><updated>2021-05-28T00:00:00+00:00</updated><entry><title>The Linux Kernel Coding Style</title><link href="https://0x42.sh/the-linux-kernel-coding-style/" rel="alternate"/><published>2021-05-28T00:00:00+00:00</published><updated>2021-05-28T00:00:00+00:00</updated><author><name>bryan brattlof</name></author><id>tag:0x42.sh,2021-05-28:/the-linux-kernel-coding-style/</id><summary type="html">&lt;p&gt;Like the (very) old saying goes: &lt;em&gt;&amp;quot;Beauty is in the eye of the
beholder&amp;quot;&lt;/em&gt;. This old (Greek maybe?) saying even holds true for the
software we write. The Linux kernel, like any sufficiently large
software project, with thousands of developers each having their own
ideas of beautifully readable code, the …&lt;/p&gt;</summary><content type="html">&lt;p&gt;Like the (very) old saying goes: &lt;em&gt;&amp;quot;Beauty is in the eye of the
beholder&amp;quot;&lt;/em&gt;. This old (Greek maybe?) saying even holds true for the
software we write. The Linux kernel, like any sufficiently large
software project, with thousands of developers each having their own
ideas of beautifully readable code, the issue of how the code looks
eventually becomes a topic of discussion.&lt;/p&gt;
&lt;p&gt;These coding style standards, while sometimes annoying, are essential to
letting developers worry about developing rather than trying to decipher
another developer's &lt;em&gt;&amp;quot;beautifully&amp;quot;&lt;/em&gt; written code.&lt;/p&gt;
&lt;p&gt;So for the 4&lt;sup&gt;th&lt;/sup&gt; challenge in &lt;a class="reference external" href="https://eudyptula-challenge.org/"&gt;The Eudyptula Challenge&lt;/a&gt; we'll
return our focus on the &lt;a class="reference external" href="https://0x42.sh/the-hello-world-kernel-module/"&gt;Hello World Kernel Module&lt;/a&gt; we
created in the 1&lt;sup&gt;st&lt;/sup&gt; challenge, bringing it up to the (charmingly
unique) Linux kernel coding standard of what beautifully written C code
looks like.&lt;/p&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;Brief Aside:&lt;/p&gt;
&lt;p&gt;Before we begin, this is the 4&lt;sup&gt;th&lt;/sup&gt; write-up &lt;a class="reference external" href="https://0x42.sh/eudyptula-challenge/"&gt;in a series&lt;/a&gt; as I work through &lt;a class="reference external" href="https://eudyptula-challenge.org/"&gt;The Eudyptula Challenge&lt;/a&gt;.
If you wish to work on The Eudyptula Challenge yourself before you
read my notes (recommended), you can use &lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula"&gt;my git repository&lt;/a&gt; which has all 20 tasks and
the code I used to complete each one.&lt;/p&gt;
&lt;p class="last"&gt;Or you can start with the 1&lt;sup&gt;st&lt;/sup&gt; challenge of this series I've
published &lt;a class="reference external" href="https://0x42.sh/eudyptula-challenge/"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;&lt;em&gt;Enjoy!&lt;/em&gt;&lt;/p&gt;
&lt;div class="section" id="task-no-4"&gt;
&lt;h2&gt;Task No.4&lt;/h2&gt;
&lt;blockquote&gt;
&lt;p&gt;Wonderful job in making it this far, I hope you have been having fun.
Oh, you're getting bored, just booting and installing kernels?  Well,
time for some pedantic things to make you feel that those kernel builds
are actually fun!&lt;/p&gt;
&lt;p&gt;Part of the job of being a kernel developer is recognizing the proper
Linux kernel coding style. The full description of this coding style
can be found in the kernel itself, in the &lt;code&gt;Documentation/CodingStyle&lt;/code&gt;
file.  I'd recommend going and reading that right now, it's pretty
simple stuff, and something that you are going to need to know and
understand.  There is also a tool in the kernel source tree in the
&lt;code&gt;scripts/&lt;/code&gt; directory called &lt;code&gt;checkpatch.pl&lt;/code&gt; that can be used
to test for adhering to the coding style rules, as kernel programmers are
lazy and prefer to let scripts do their work for them...&lt;/p&gt;
&lt;p&gt;And why a coding standard at all?  That's because of your brain (yes,
yours, not mine, remember, I'm just some dumb shell scripts).  Once your
brain learns the patterns, the information contained really starts to
sink in better.  So it's important that everyone follow the same
standard so that the patterns become consistent. In other words, you
want to make it really easy for other people to find the bugs in your
code, and not be confused and distracted by the fact that you happen to
prefer 5 spaces instead of tabs for indentation. Of course you would
never prefer such a thing, I'd never accuse you of that, it was just an
example, please forgive my impertinence!&lt;/p&gt;
&lt;p&gt;Anyway, the tasks for this round all deal with the Linux kernel coding
style. Attached to this message are two kernel modules that do not
follow the proper Linux kernel coding style rules. Please fix both of
them up, and send it back to me in such a way that does follow the
rules.&lt;/p&gt;
&lt;p&gt;What, you recognize one of these modules?  Imagine that, perhaps I was
right to accuse you of the using a &lt;em&gt;&amp;quot;wrong&amp;quot;&lt;/em&gt; coding style :)&lt;/p&gt;
&lt;p&gt;Yes, the logic in the second module is crazy, and probably wrong, but
don't focus on that, just look at the patterns here, and fix up the
coding style, do not remove lines of code.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Attachments:&lt;/strong&gt;&lt;/p&gt;
&lt;ol class="arabic simple"&gt;
&lt;li&gt;&lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula/tree/ba717131952f892d88459a265915563796683347/item/tasks/01/hello-world.c"&gt;hello_world.c&lt;/a&gt; - &lt;strong&gt;Note:&lt;/strong&gt; This should be the module you submitted
from the &lt;a class="reference external" href="https://0x42.sh/the-hello-world-kernel-module/"&gt;First Eudyptula Challenge&lt;/a&gt;. If you've
been following along, this is the file we submitted.&lt;/li&gt;
&lt;li&gt;&lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula/tree/ba717131952f892d88459a265915563796683347/item/tasks/04/coding_style.c"&gt;coding_style.c&lt;/a&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;p class="attribution"&gt;&amp;mdash;Little Penguin&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;As the Little Penguin was saying, the Linux &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/process/coding-style.html"&gt;style guide&lt;/a&gt; is here not
for &lt;strong&gt;your&lt;/strong&gt; benefit, but to help other developers, maintainers, and
reviewers understand and evaluate the code you write faster. The kernel
works at a &lt;strong&gt;furious&lt;/strong&gt; pace, receiving on average &lt;strong&gt;~10 patches every
hour&lt;/strong&gt;, a pace that is only accelerating as more people and companies
begin to depend on the project for the new device, radio, microwave or
any other IoT gadget they're working on.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;TLDR:&lt;/strong&gt; The style guide helps everyone review your code which improves
the chances of your patch being accepted.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="executive-summary-of-the-linux-kernel-coding-style"&gt;
&lt;h2&gt;Executive Summary of the &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/process/coding-style.html"&gt;Linux Kernel Coding Style&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;The &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/process/coding-style.html"&gt;style guide&lt;/a&gt; is a very straight forward document, the majority of
it dealing with whitespace and naming things. (Something every project
has to deal with regardless the number of developers it has) I'll list
the &lt;em&gt;&amp;quot;executive overview&amp;quot;&lt;/em&gt; here (for the SEO points 🙂) though you
should really take a moment to skim the Linux coding &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/process/coding-style.html"&gt;style guide&lt;/a&gt; for
the latest updates.&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;&lt;strong&gt;tabs are 8 characters, one statement per line.&lt;/strong&gt; Historically tab
keys were used &lt;a class="reference external" href="https://en.wikipedia.org/wiki/Tab_key"&gt;to help tabulate charts&lt;/a&gt; on typewriters. Now they
help maintainers keep track of your control blocks.&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;&lt;p class="first"&gt;&lt;strong&gt;80 characters per line.&lt;/strong&gt; An old throwback to when screens only
displayed 80 characters per line. &lt;em&gt;&amp;quot;Now-O-Days&amp;quot;&lt;/em&gt;, with modern 48&amp;quot; 8k
monitors, the 80 character hard limit is a bit softer.  Today we can
get away with a few lines under 100 characters if it improves
readability.  One possible exception to this is &lt;code&gt;printk()&lt;/code&gt;
statements, allowing us to easily &lt;code&gt;grep&lt;/code&gt; for them when
debugging.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p class="first"&gt;&lt;strong&gt;brackets.&lt;/strong&gt; Don't worry about brackets if you only need one line.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="k"&gt;if&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;err&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;span class="w"&gt;        &lt;/span&gt;&lt;span class="k"&gt;return&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;ENOMEM&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;For multiple lines, place the bracket at the end of your if (switch,
do, for, while, ...) statements.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="k"&gt;if&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;err&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="p"&gt;{&lt;/span&gt;
&lt;span class="w"&gt;        &lt;/span&gt;&lt;span class="n"&gt;pr_dbg&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;Failed to allocate memory&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;span class="w"&gt;        &lt;/span&gt;&lt;span class="k"&gt;return&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="o"&gt;-&lt;/span&gt;&lt;span class="n"&gt;ENOMEM&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt;
&lt;span class="p"&gt;}&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Though function have brackets on the next new line.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="kt"&gt;int&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nf"&gt;do_something_cool&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="kt"&gt;void&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;span class="p"&gt;{&lt;/span&gt;
&lt;span class="w"&gt;        &lt;/span&gt;&lt;span class="k"&gt;return&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="n"&gt;something_cool&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="o"&gt;==&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="n"&gt;DONE&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt;
&lt;span class="p"&gt;}&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p class="first"&gt;&lt;strong&gt;spaces.&lt;/strong&gt; Most of the time, spaces go after each keyword. Some
notable exceptions to this are &lt;code&gt;sizeof&lt;/code&gt;, &lt;code&gt;typeof&lt;/code&gt;,
&lt;code&gt;alignof&lt;/code&gt;, and &lt;code&gt;__attribute__&lt;/code&gt; which are treaded somewhat
like functions in the kernel.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p class="first"&gt;&lt;strong&gt;naming.&lt;/strong&gt; Don't worry about descriptive variable names inside a
function. &lt;code&gt;tmp&lt;/code&gt; or &lt;code&gt;err&lt;/code&gt; are perfectly acceptable.
However global variables (to be used sparingly) should have
descriptive names. Don't use &lt;em&gt;MixedCase!&lt;/em&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p class="first"&gt;&lt;strong&gt;typedefs.&lt;/strong&gt; Just &lt;em&gt;Don't&lt;/em&gt;. Typedefs only hurt readability. You can't
immediately tell if it's a &lt;code&gt;struct&lt;/code&gt; or an integer of some
specific size, or a pointer (to a pointer, to a pointer...  to...).&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p class="first"&gt;&lt;strong&gt;commenting your code.&lt;/strong&gt; If your explaining &lt;em&gt;how&lt;/em&gt; the code works,
you've written it wrong. Comments are for &lt;em&gt;what&lt;/em&gt; your code does if the
function's name didn't make this clear already.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;These bullets take care of the majority of what a &lt;strong&gt;new&lt;/strong&gt; kernel
developer will deal with on a day-to-day basis, and if you're ever
unsure about something you can always &lt;code&gt;git grep &amp;lt;pattern&amp;gt;&lt;/code&gt; to see
how others have coded similar things in the past.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="scripts-checkpatch-pl"&gt;
&lt;h2&gt;scripts/checkpatch.pl&lt;/h2&gt;
&lt;p&gt;Fortunately, previous developers created a script to check for &lt;strong&gt;some&lt;/strong&gt;
of these style blunders and alleviate the burden put on maintainers to
point out these minor coding style violations. This script is one of
many helpful scripts inside the Linux source tree we &lt;a class="reference external" href="https://0x42.sh/building-the-linux-kernel/#cloning"&gt;downloaded in the
second challenge&lt;/a&gt;.  The one we're interested in and we will
be using today is called &lt;code&gt;scripts/checkpatch.pl&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;At the root of the Linux source code, use the &lt;code&gt;--help&lt;/code&gt; or
&lt;code&gt;--version&lt;/code&gt; options to see the usage instructions and get a
complete list of all the options available.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ ./scripts/checkpatch.pl --help
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;For this Eudyptula Challenge, we will remain focused on the
&lt;code&gt;--file&lt;/code&gt; or &lt;code&gt;-f&lt;/code&gt; option to analyze the files the little
penguin gave us (&lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula/tree/ba717131952f892d88459a265915563796683347/item/tasks/01/hello-world.c"&gt;hello_world.c&lt;/a&gt; and &lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula/tree/ba717131952f892d88459a265915563796683347/item/tasks/04/coding_style.c"&gt;coding_style.c&lt;/a&gt;) for style
violations. I won't go into the specific changes we need to make (a task
for you to complete). Instead I will go through how to use
&lt;code&gt;checkpatch.pl&lt;/code&gt; to find some of issues with the files the Little
Penguin gave us.&lt;/p&gt;
&lt;p&gt;We can check our file using the &lt;code&gt;-f&lt;/code&gt; option followed by the file
we want to check:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ ./scripts/checkpatch.pl -f ~/eudyptupla/tasks/04/coding_style.c
...
total: 1 errors, 1 warnings, 1 checks, 35 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

eudyptupla/tasks/04/coding_style.c has style problems, please review.
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Then use you favorite editor to fix the issues &lt;code&gt;checkpatch.pl&lt;/code&gt;
printed out.&lt;/p&gt;
&lt;p&gt;You can even use &lt;code&gt;--strict&lt;/code&gt; or the &lt;code&gt;--subjective&lt;/code&gt; option to
enable more subjective tests and &lt;code&gt;--codespell&lt;/code&gt; to check the file
for misspelled words.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ ./scripts/checkpatch.pl --strict --codespell -f ~/eudyptula ...
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;Keep in mind!&lt;/p&gt;
&lt;p class="last"&gt;&lt;code&gt;checkpatch.pl&lt;/code&gt; will find &lt;strong&gt;some&lt;/strong&gt; of the style issues. Consult
the &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/process/coding-style.html"&gt;style guide&lt;/a&gt; to find all the needed changes.&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;Once you've made your changes, and feel the code looks good (it's hard
when you can remove any lines) use &lt;code&gt;git format-patch HEAD~&lt;/code&gt; and
send in your changes.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Good Luck!&lt;/em&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="wrapping-up"&gt;
&lt;h2&gt;Wrapping Up&lt;/h2&gt;
&lt;p&gt;If you made it here, you may be surprised to see how little there was to
this challenge. Essentially this &lt;em&gt;&amp;quot;boils down&amp;quot;&lt;/em&gt; to reading the Linux
&lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/process/coding-style.html"&gt;style guide&lt;/a&gt; and practice using it. Though, so far in my software
career, I have found that true for all coding standards.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;PS:&lt;/strong&gt; I made around 39 changes in all, though this may change
depending on &lt;em&gt;when&lt;/em&gt; you work on this.  Hope that helps :)&lt;/p&gt;
&lt;/div&gt;
</content><category term="Notes"/><category term="Eudyptula Challenge"/></entry><entry><title>Modify The Linux Kernel</title><link href="https://0x42.sh/modify-the-linux-kernel/" rel="alternate"/><published>2020-08-15T00:00:00+00:00</published><updated>2020-08-15T00:00:00+00:00</updated><author><name>bryan brattlof</name></author><id>tag:0x42.sh,2020-08-15:/modify-the-linux-kernel/</id><summary type="html">&lt;p&gt;For the 3&lt;sup&gt;rd&lt;/sup&gt; task (this task) in &lt;a class="reference external" href="https://eudyptula-challenge.org"&gt;The Eudyptula Challenge&lt;/a&gt;, we continue our work from &lt;a class="reference external" href="https://0x42.sh/building-the-linux-kernel/"&gt;the last
challenge&lt;/a&gt;, compiling the
absolute latest Linux Kernel from the source code. This time we focus on
modifying the Makefiles and &lt;code&gt;.config&lt;/code&gt; files that help us compile the
kernel.&lt;/p&gt;
&lt;p&gt;Before we begin, if …&lt;/p&gt;</summary><content type="html">&lt;p&gt;For the 3&lt;sup&gt;rd&lt;/sup&gt; task (this task) in &lt;a class="reference external" href="https://eudyptula-challenge.org"&gt;The Eudyptula Challenge&lt;/a&gt;, we continue our work from &lt;a class="reference external" href="https://0x42.sh/building-the-linux-kernel/"&gt;the last
challenge&lt;/a&gt;, compiling the
absolute latest Linux Kernel from the source code. This time we focus on
modifying the Makefiles and &lt;code&gt;.config&lt;/code&gt; files that help us compile the
kernel.&lt;/p&gt;
&lt;p&gt;Before we begin, if you wish to work on The Eudyptula Challenge yourself before
you read my notes (recommended), you can use &lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula"&gt;my git repository&lt;/a&gt;, which has all 20
tasks and the code I used to complete each one.&lt;/p&gt;
&lt;div class="section" id="task-no-3"&gt;
&lt;h2&gt;Task No.3&lt;/h2&gt;
&lt;blockquote&gt;
&lt;p&gt;Now that you have your custom kernel up and running, it's time to modify
it!&lt;/p&gt;
&lt;p&gt;The tasks for this round is:&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;take the kernel git tree from Task 02 and modify the Makefile to
and modify the EXTRAVERSION field.  Do this in a way that the
running kernel (after modifying the Makefile, rebuilding, and
rebooting) has the characters &amp;quot;-eudyptula&amp;quot; in the version string.&lt;/li&gt;
&lt;li&gt;show proof of booting this kernel.  Extra cookies for you by
providing creative examples, especially if done in interpretive
dance at your local pub.&lt;/li&gt;
&lt;li&gt;Send a patch that shows the Makefile modified.  Do this in a manner
that would be acceptable for merging in the kernel source tree.
(Hint, read the file Documentation/SubmittingPatches and follow the
steps there.)&lt;/li&gt;
&lt;/ul&gt;
&lt;p class="attribution"&gt;&amp;mdash;Little Penguin&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Depending on how literally we interpret &lt;em&gt;&amp;quot;modifying the Makefile&amp;quot;&lt;/em&gt;, there are
multiple ways we can accomplish this challenge. One of which we briefly talked
about in &lt;a class="reference external" href="https://0x42.sh/building-the-linux-kernel/"&gt;the last challenge&lt;/a&gt; was to override variables
in our &lt;code&gt;make&lt;/code&gt; command when compiling the kernel.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="override-directives"&gt;
&lt;h2&gt;Override Directives&lt;/h2&gt;
&lt;p&gt;Just like with a lot of userspace projects, the Linux kernel uses &lt;a class="reference external" href="https://www.gnu.org/software/make/"&gt;GNU make&lt;/a&gt; to compile the various files into its
final form. This means we can use make's ability to pass variable assignments as
command line arguments.&lt;/p&gt;
&lt;p&gt;From Chapter 6 of make's &lt;a class="reference external" href="https://www.gnu.org/software/make/manual/html_node/Override-Directive.html"&gt;documentation&lt;/a&gt;, if we use a command line argument to set
the &lt;code&gt;EXTRAVERSION&lt;/code&gt; variable, then all other assignments to
&lt;code&gt;EXTRAVERSION&lt;/code&gt; within the Makefile will be ignored. For example, we can
override &lt;code&gt;EXTRAVERSION&lt;/code&gt; by using a &lt;code&gt;make&lt;/code&gt; command like this:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make -j `getconf _NPROCESSORS_ONLN` EXTRAVERSION=-eudyptula
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This will force &lt;code&gt;make&lt;/code&gt; to set &lt;code&gt;EXTRAVERSION&lt;/code&gt; to &lt;code&gt;-eudyptula&lt;/code&gt;
and ignore the value set in the kernel's Makefile, accomplishing our task for The
Little Penguin.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="modify-the-makefile"&gt;
&lt;h2&gt;Modify the Makefile&lt;/h2&gt;
&lt;p&gt;Our second option, if you want to take &lt;em&gt;&amp;quot;modifying the Makefile&amp;quot;&lt;/em&gt; literally, is
to do exactly that.&lt;/p&gt;
&lt;p&gt;Simply open the kernel's Makefile, located in the root directory in the source
code we copied from Linus in &lt;a class="reference external" href="https://0x42.sh/building-the-linux-kernel/"&gt;the last challenge&lt;/a&gt;, with your favorite text editor. The first five
lines will have &lt;code&gt;EXTRAVERSION&lt;/code&gt; somewhere in it. Change the value to
&lt;code&gt;-eudyptula&lt;/code&gt; and save.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="gd"&gt;-EXTRAVERSION = -rc1&lt;/span&gt;
&lt;span class="gi"&gt;+EXTRAVERSION = -eudyptula&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Now that the kernel's Makefile will append &lt;code&gt;-eudyptula&lt;/code&gt; to the kernel's
version string by default, we can simplify our &lt;code&gt;make&lt;/code&gt; command to build the
kernel into:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make -j `getconf _NPROCESSORS_ONLN`
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="modify-menuconfig"&gt;
&lt;h2&gt;Modify menuconfig&lt;/h2&gt;
&lt;p&gt;Our third option and arguably the least accurate of the three ways to
interpret &lt;em&gt;&amp;quot;modifying the Makefile&amp;quot;&lt;/em&gt; is to use the ncurses configuration tool
that we briefly talked about in &lt;a class="reference external" href="https://0x42.sh/building-the-linux-kernel/"&gt;the last challenge&lt;/a&gt;. I say this is the least
accurate because this method modifies the &lt;code&gt;CONFIG_LOCALVERSION&lt;/code&gt; variable
and not the &lt;code&gt;EXTRAVERSION&lt;/code&gt; variable, which will add &lt;code&gt;-eudyptula&lt;/code&gt; to
our kernel's version string, however not technically in the correct place.&lt;/p&gt;
&lt;p&gt;We can start the ncurses menu with the following terminal command:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make menuconfig
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;where you should see a screen that looks something like this:&lt;/p&gt;
&lt;img alt="Something" src="https://0x42.sh/modify-the-linux-kernel/menuconfig-home.png" /&gt;
&lt;p&gt;From here, navigate to the &lt;strong&gt;General setup&lt;/strong&gt; option and press &lt;strong&gt;ENTER&lt;/strong&gt; to move
into the next menu. Next, use the arrow keys to highlight the &lt;strong&gt;Local version&lt;/strong&gt;
option and press &lt;strong&gt;ENTER&lt;/strong&gt;. A new menu will appear letting you enter a value.&lt;/p&gt;
&lt;img alt="Else" src="https://0x42.sh/modify-the-linux-kernel/menuconfig-localversion.png" /&gt;
&lt;p&gt;Type in &lt;strong&gt;-eudyptula&lt;/strong&gt; and press &lt;strong&gt;TAB&lt;/strong&gt; to move our cursor to the &lt;strong&gt;&amp;lt;OK&amp;gt;&lt;/strong&gt;
option and press &lt;strong&gt;ENTER&lt;/strong&gt; to return back to the &lt;strong&gt;General setup&lt;/strong&gt; menu. If
everything went according to plan you should see &lt;em&gt;&amp;quot;-eudyptula&amp;quot;&lt;/em&gt; set in the Local
version menu:&lt;/p&gt;
&lt;img alt="else" src="https://0x42.sh/modify-the-linux-kernel/menuconfig-eudyptula.png" /&gt;
&lt;p&gt;From here, press &lt;strong&gt;TAB&lt;/strong&gt; a few more times to move our cursor to highlight the
&lt;strong&gt;&amp;lt;SAVE&amp;gt;&lt;/strong&gt; option at the bottom. Then press &lt;strong&gt;ENTER&lt;/strong&gt; to save the changes we made
to our &lt;code&gt;.config&lt;/code&gt; file.&lt;/p&gt;
&lt;p&gt;After we've saved our changes press &lt;strong&gt;TAB&lt;/strong&gt; a couple more times to highlight
the &lt;strong&gt;&amp;lt;EXIT&amp;gt;&lt;/strong&gt; option and &lt;strong&gt;ENTER&lt;/strong&gt; to exit the ncurses menu.&lt;/p&gt;
&lt;p&gt;Finally, with the changes to our &lt;code&gt;.config&lt;/code&gt; file saved, we can re-compile
our kernel with the same simpified command &lt;a class="reference internal" href="#modify-the-makefile"&gt;from above&lt;/a&gt;:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make -j `getconf _NPROCESSORS_ONLN`
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
</content><category term="Notes"/><category term="Eudyptula Challenge"/></entry><entry><title>Building The Linux Kernel</title><link href="https://0x42.sh/building-the-linux-kernel/" rel="alternate"/><published>2020-07-31T00:00:00+00:00</published><updated>2020-07-31T00:00:00+00:00</updated><author><name>bryan brattlof</name></author><id>tag:0x42.sh,2020-07-31:/building-the-linux-kernel/</id><summary type="html">&lt;p&gt;Previously, for the 1&lt;sup&gt;st&lt;/sup&gt; task in &lt;a class="reference external" href="https://eudyptula-challenge.org"&gt;The Eudyptula Challenge&lt;/a&gt;, we built a Loadable Kernel Module (LKM)
that adds &lt;em&gt;&amp;quot;Hello World&amp;quot;&lt;/em&gt; to our kernel's message buffer any time the module is
installed. You can read my notes all &lt;a class="reference external" href="https://0x42.sh/the-hello-world-kernel-module/"&gt;about that here&lt;/a&gt; if you want to
learn more.&lt;/p&gt;
&lt;p&gt;Or, if you …&lt;/p&gt;</summary><content type="html">&lt;p&gt;Previously, for the 1&lt;sup&gt;st&lt;/sup&gt; task in &lt;a class="reference external" href="https://eudyptula-challenge.org"&gt;The Eudyptula Challenge&lt;/a&gt;, we built a Loadable Kernel Module (LKM)
that adds &lt;em&gt;&amp;quot;Hello World&amp;quot;&lt;/em&gt; to our kernel's message buffer any time the module is
installed. You can read my notes all &lt;a class="reference external" href="https://0x42.sh/the-hello-world-kernel-module/"&gt;about that here&lt;/a&gt; if you want to
learn more.&lt;/p&gt;
&lt;p&gt;Or, if you wish to work on The Eudyptula Challenge yourself before you read my
notes (recommended), you can use &lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula"&gt;my git repository&lt;/a&gt;, which has all 20 tasks and the
code I used to complete each one.&lt;/p&gt;
&lt;p&gt;For this challenge, the 2&lt;sup&gt;nd&lt;/sup&gt; task of The Eudyptula Challenge, we will
use the Kbuild system once again. This time we will use the Kbuild system to
compile the latest version of the Linux Kernel. Then after compiling it (this
takes some time), we install and boot from it.&lt;/p&gt;
&lt;div class="section" id="task-no-2"&gt;
&lt;h2&gt;Task No.2&lt;/h2&gt;
&lt;blockquote&gt;
&lt;p&gt;Now that you have written your first kernel module, it's time to take
off the training wheels and move on to building a custom kernel.  No
more distro kernels for you, for this task you must run your own kernel.
And use git!  Exciting isn't it!  No, oh, ok...&lt;/p&gt;
&lt;p&gt;The tasks for this round is:&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;download Linus's latest git tree from git.kernel.org (you have to
figure out which one is his, it's not that hard, just remember what
his last name is and you should be fine.)&lt;/li&gt;
&lt;li&gt;build it, install it, and boot it.  You can use whatever kernel
configuration options you wish to use, but you must enable
CONFIG_LOCALVERSION_AUTO=y.&lt;/li&gt;
&lt;li&gt;show proof of booting this kernel.  Bonus points for you if you do
it on a &amp;quot;real&amp;quot; machine, and not a virtual machine (virtual machines
are acceptable, but come on, real kernel developers don't mess
around with virtual machines, they are too slow.  Oh yeah, we aren't
real kernel developers just yet.  Well, I'm not anyway, I'm just a
script...)  Again, proof of running this kernel is up to you, I'm
sure you can do well.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Hint, you should look into the 'make localmodconfig' option, and base
your kernel configuration on a working distro kernel configuration.
Don't sit there and answer all 1625 different kernel configuration
options by hand, even I, a foolish script, know better than to do that!&lt;/p&gt;
&lt;p&gt;After doing this, don't throw away that kernel and git tree and
configuration file.  You'll be using it for later tasks, a working
kernel configuration file is a precious thing, all kernel developers
have one they have grown and tended to over the years.  This is the
start of a long journey with yours, don't discard it like was a broken
umbrella, it deserves better than that.&lt;/p&gt;
&lt;p class="attribution"&gt;&amp;mdash;Little Penguin&lt;/p&gt;
&lt;/blockquote&gt;
&lt;/div&gt;
&lt;div class="section" id="build-tools"&gt;
&lt;h2&gt;Build Tools&lt;/h2&gt;
&lt;p&gt;Just like mechanics, plumbers, and all the other skilled trades, having the
right tools for the job makes a world of difference. This &lt;em&gt;&amp;quot;tools maketh man&amp;quot;&lt;/em&gt;
proverb rings true even for software developers, even though most of our tools
are less tangible.&lt;/p&gt;
&lt;p&gt;The tools we will need to properly build the kernel vary wildly depending on
many factors, like your hardware, kernel version, how we plan to install the
kernel, as well as the linux distribution on your computer. All the &lt;em&gt;minimum&lt;/em&gt;
requirements we will need to build the kernel are listed in &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/process/changes.html"&gt;the documentation
here&lt;/a&gt;, chances
are though you will need to use more.&lt;/p&gt;
&lt;p&gt;The tools I needed to build version 5.8 of the kernel on my (charmingly retro)
Lenovo T430, running Ubuntu's 18.04 LTS (Bionic Beaver) release, are easily
installed with:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ sudo apt install build-essential libncurses-dev bison flex libssl-dev libelf-dev
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="cloning"&gt;
&lt;h2&gt;Cloning&lt;/h2&gt;
&lt;p&gt;When you first navigate to the &lt;a class="reference external" href="https://git.kernel.org"&gt;kernel's git repositories&lt;/a&gt;, you will be greeted with hundreds of projects all
having something to do with archiving or improving the Linux Kernel in some way.
To help simplify the process of finding Linus' repository, which has the latest
patches, we can search through the projects listed (using &lt;strong&gt;Ctrl+F&lt;/strong&gt;) for
&lt;strong&gt;&amp;quot;torvalds/&amp;quot;&lt;/strong&gt;.&lt;/p&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;If you still have problems finding Linus' repository, you can cheat with &lt;a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/"&gt;this
URL&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;Once you have found the URL, we can use &lt;code&gt;git&lt;/code&gt; to download a copy of Linus'
Linux repository using the typical &lt;code&gt;git clone&lt;/code&gt; command. If you are unsure
about how to clone a repository, the &lt;a class="reference external" href="https://git-scm.com/doc"&gt;git documentation&lt;/a&gt; has a great article about &lt;a class="reference external" href="https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository"&gt;getting started with git&lt;/a&gt;.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ git clone https://git.kernel.org/pub/scm/linux ...
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;The Linux Project is big (~3GB). If you have a slower internet connection,
you can add &lt;code&gt;--depth=256&lt;/code&gt; to the &lt;code&gt;git clone&lt;/code&gt; command above to
create a &lt;a class="reference external" href="https://www.git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt"&gt;&amp;quot;shallow clone&amp;quot;&lt;/a&gt;
which limits the number of older patches you need to download and still have
a functioning copy of the kernel's source code.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="configuring"&gt;
&lt;h2&gt;Configuring&lt;/h2&gt;
&lt;p&gt;With a copy of the kernel's source code in hand, our next task is to set the
many thousands of configuration options needed for the &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/kbuild/index.html"&gt;Kbuild System&lt;/a&gt; to properly
compile our kernel. Each configuration option, like the
&lt;code&gt;CONFIG_LOCALVERSION_AUTO&lt;/code&gt; the Little Penguin mentioned in &lt;a class="reference internal" href="#task-no-2"&gt;the challenge
message above&lt;/a&gt;, informs the Kbuild System of the drivers and
features needed to be installed to function properly with our computer's hardware.&lt;/p&gt;
&lt;p&gt;However, instead of setting roughly 8700 config options by hand, one-at-a-time
(a &lt;em&gt;very&lt;/em&gt; error prone, time consuming process), we can copy the configuration
file from the linux distribution currently running on our computer as a sort of
starting point.&lt;/p&gt;
&lt;div class="section" id="configuration-plagiarism"&gt;
&lt;h3&gt;Configuration Plagiarism&lt;/h3&gt;
&lt;p&gt;The first step in copying our distribution's configuration file is to find it
in our &lt;code&gt;/boot&lt;/code&gt; directory.&lt;/p&gt;
&lt;p&gt;There are multiple configuration files inside our &lt;code&gt;/boot&lt;/code&gt; directory. The
one our computer is using depends on the kernel version our computer is using.
For example my computer, using kernel version &lt;code&gt;4.15.0-112&lt;/code&gt;, will have a
configuration file named &lt;code&gt;config-4.15.0-112-generic&lt;/code&gt; in the &lt;code&gt;/boot&lt;/code&gt;
directory.&lt;/p&gt;
&lt;p&gt;To copy your distribution's config file into the root directory of the kernel
use the this command:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ cp /boot/config-`uname -r` .config
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Next, answer &lt;code&gt;yes&lt;/code&gt; to any new configuration options added between the
release of our distribution's kernel (they usually lag behind a few versions)
and the bleeding edge we've downloaded from Linus.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ yes &amp;quot;&amp;quot; | make oldconfig
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;Combined, these commands are equivalent to &lt;code&gt;make localyesconfig&lt;/code&gt; found in
&lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/admin-guide/README.html#configuring-the-kernel"&gt;the kernel documentation&lt;/a&gt;.
I find it nice to see &lt;em&gt;&amp;quot;how the sausage is made&amp;quot;&lt;/em&gt; though.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="configuring-by-hand"&gt;
&lt;h3&gt;Configuring By Hand&lt;/h3&gt;
&lt;p&gt;While not technically needed to complete this eudyptula challenge, this is a
good place to talk about how we can customize our newly copied configuration
file for our kernels. While there are a few, largely similar, commands that help
us edit the &lt;code&gt;.config&lt;/code&gt; file, the command I prefer is a &lt;a class="reference external" href="https://en.wikipedia.org/wiki/Ncurses"&gt;ncurses&lt;/a&gt; based menu that can run
on most systems or on remote servers if wanted.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make menuconfig
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;It produces a color menu, full of radio-lists and dialogues, that looks
something like this:&lt;/p&gt;
&lt;img alt="A screens shot of the menuconfig dialog for the 5.8.0-rc7 kernel." src="https://0x42.sh/building-the-linux-kernel/ncurses.png" /&gt;
&lt;p&gt;Each menu option allows us to enable and disable certain features in our
kernels, along with anything that depended on that option. For example, if we
disabled &lt;strong&gt;Networking&lt;/strong&gt;, all network-related options, like &lt;strong&gt;Amateur Radio&lt;/strong&gt;,
will also be disabled.&lt;/p&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;It is easy to remove an option from our kernel that will ultimately leave us
with a broken kernel. When in doubt, leave the option enabled unless you know
what you are removing.&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;The full list of commands used to edit the kernel's configuration file is
available to you in the &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/admin-guide/README.html#configuring-the-kernel"&gt;kernel documentation&lt;/a&gt;, if you want to learn more.
They largely use different &lt;a class="reference external" href="https://en.wikipedia.org/wiki/Graphical_user_interface"&gt;GUIs&lt;/a&gt; to edit our
&lt;code&gt;.config&lt;/code&gt; file.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="building"&gt;
&lt;h2&gt;Building&lt;/h2&gt;
&lt;p&gt;With all the preparations complete, we can start to work on compiling the kernel
into a compressed image ready for our computers. Just like in userspace
applications, a simple &lt;code&gt;make&lt;/code&gt; command is all that is needed to build
our kernel:&lt;/p&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;WARNING:&lt;/p&gt;
&lt;p class="last"&gt;Building the kernel will take a significant amount of time.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make -j `getconf _NPROCESSORS_ONLN` CONFIG_LOCALVERSION_AUTO=y LOCALVERSION=-eudyptula
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;While a bare &lt;code&gt;make&lt;/code&gt; command, without the added arguments, will also work
to build our kernel, however, the kernel is such a large project, using the
&lt;code&gt;-j&lt;/code&gt; flag to compile multiple files at the same time will dramatically
reduce the total time needed to compile.&lt;/p&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;&lt;code&gt;getconf _NPROCESSORS_ONLN&lt;/code&gt; determines the number of CPU cores your
computer has. You can replace this with any number you wish. For example
&lt;code&gt;make -j4&lt;/code&gt; will allow &lt;code&gt;make&lt;/code&gt; to compile 4 targets at a time,
consuming 4 of your CPU's cores. You can read more about how &lt;a class="reference external" href="https://www.gnu.org/software/make/manual/html_node/Parallel.html"&gt;Parallel
Execution&lt;/a&gt;
works in the &lt;code&gt;make&lt;/code&gt; documentation.&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;We are also passing two extra configuration options with the &lt;code&gt;make&lt;/code&gt;
command above:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="nv"&gt;CONFIG_LOCALVERSION_AUTO&lt;/span&gt;&lt;span class="o"&gt;=&lt;/span&gt;y&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nv"&gt;LOCALVERSION&lt;/span&gt;&lt;span class="o"&gt;=&lt;/span&gt;-eudyptula
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Both of these configuration options will add information to our kernel's version
string, helping us prove to The Little Penguin we installed the latest kernel
published by Linus Torvalds.&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;The &lt;code&gt;CONFIG_LOCALVERSION_AUTO&lt;/code&gt; option will append enough characters from
the latest &lt;a class="reference external" href="https://git-scm.com/book/en/v2/Git-Internals-Git-Objects"&gt;commit id&lt;/a&gt;
to be unique in our kernel's version name. For me this was &lt;code&gt;g1df0d8960499&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;LOCALVERSION&lt;/code&gt; will also add &lt;code&gt;-eudyptula&lt;/code&gt; to that same version string&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;producing a kernel named something like this:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;linux-image-5.8.0-rc4-eudyptula-00381-g1df0d8960499
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="installing"&gt;
&lt;h2&gt;Installing&lt;/h2&gt;
&lt;p&gt;Our last and final step to completing this challenge is to install the kernel
along with its supporting modules into our &lt;code&gt;/boot&lt;/code&gt; and &lt;code&gt;/lib/modules&lt;/code&gt;
folders. This will allow our boot loader, &lt;a class="reference external" href="https://www.gnu.org/software/grub/"&gt;GRUB&lt;/a&gt;, to properly initialize our freshly
compiled linux kernel the next time we reboot.&lt;/p&gt;
&lt;p&gt;Each distribution of linux installs the kernel in their way. For example &lt;a class="reference external" href="https://wiki.archlinux.org/index.php/Kernel/Traditional_compilation#Installation"&gt;Arch
Linux's documentation&lt;/a&gt;
tells us to manually copy (with &lt;code&gt;cp&lt;/code&gt;) and &lt;em&gt;not&lt;/em&gt; to use &lt;code&gt;make install&lt;/code&gt;
to install the kernel in our &lt;code&gt;/boot&lt;/code&gt; directory. All this to say &lt;em&gt;&amp;quot;your mileage
may vary&amp;quot;&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;For most linux distributions we can install our kernel with a simple &lt;code&gt;make&lt;/code&gt;
command:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ sudo make modules_install install
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Along with installing all the kernel's modules and the kernel itself, this
command will also update our &lt;code&gt;/boot/grub/grub.conf&lt;/code&gt; files, so we don't have
to manually update GRUB ourselves.&lt;/p&gt;
&lt;div class="section" id="ubuntu-debian-weirdness"&gt;
&lt;h3&gt;Ubuntu/Debian Weirdness&lt;/h3&gt;
&lt;p&gt;If your linux distribution has trouble with the &lt;code&gt;make install&lt;/code&gt; commands
above, an alternative is to bundle our linux kernel into a package. This method
is slower (a real pain when developing drivers) however, packages usually have
more success installing on certain systems.&lt;/p&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;There are so many linux distributions I cannot possibly test them all. For my
hardware running Ubuntu 18.04 LTS, the following commands worked.&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;For Debian and Ubuntu based distributions we can use &lt;code&gt;deb-pkg&lt;/code&gt; to generate
the packages:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make deb-pkg
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This command will generate up to 5 Debian packages:&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;&lt;code&gt;linux-image-version&lt;/code&gt; which contains the kernel image and the associated
modules.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;linux-headers-version&lt;/code&gt; has the header files required to build external
modules.&lt;/li&gt;
&lt;li&gt;&lt;code&gt;linux-firmware-image-version&lt;/code&gt; contains the firmware files needed by
some drivers (this package could be missing when you build from the kernel
sources provided by Debian).&lt;/li&gt;
&lt;li&gt;&lt;code&gt;linux-image-version-dbg&lt;/code&gt; which contains the debugging symbols for the
kernel image and its modules&lt;/li&gt;
&lt;li&gt;and &lt;code&gt;linux-libc-dev&lt;/code&gt; holds headers relevant to some user-space libraries.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;All of these packages can easily be installed with a simple &lt;code&gt;dpkg&lt;/code&gt; command:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;sudo dpkg -i ../*.deb
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;&lt;strong&gt;And that's it!&lt;/strong&gt; Reboot you computer, and run &lt;code&gt;uname -r&lt;/code&gt; and you should
see something like:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ uname -r
linux-image-5.8.0-rc4-eudyptula-00381-g1df0d8960499
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;This output will prove to The Little Penguin you've successfully compiled and
installed your first (of many I'm sure) custom linux kernel. &lt;strong&gt;Great Job!&lt;/strong&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
</content><category term="Notes"/><category term="Eudyptula Challenge"/></entry><entry><title>The Hello World Kernel Module</title><link href="https://0x42.sh/the-hello-world-kernel-module/" rel="alternate"/><published>2020-07-15T00:00:00+00:00</published><updated>2020-07-15T00:00:00+00:00</updated><author><name>bryan brattlof</name></author><id>tag:0x42.sh,2020-07-15:/the-hello-world-kernel-module/</id><summary type="html">&lt;p&gt;As a brief introduction to this (very long) essay. What lies below are
my notes while completing the 1&lt;sup&gt;st&lt;/sup&gt; in a set of 20 tasks from
&lt;a class="reference external" href="https://eudyptula-challenge.org"&gt;The Eudyptula Challenge&lt;/a&gt;. Each
task, emailed one at a time, starting with building a &amp;quot;hello world&amp;quot;
kernel module (this essay) and progressed in …&lt;/p&gt;</summary><content type="html">&lt;p&gt;As a brief introduction to this (very long) essay. What lies below are
my notes while completing the 1&lt;sup&gt;st&lt;/sup&gt; in a set of 20 tasks from
&lt;a class="reference external" href="https://eudyptula-challenge.org"&gt;The Eudyptula Challenge&lt;/a&gt;. Each
task, emailed one at a time, starting with building a &amp;quot;hello world&amp;quot;
kernel module (this essay) and progressed in difficulty until we
ultimately submit patches into the main tree of the Linux kernel. The
ultimate goal of The Eudyptula Challenge is to get new developers
comfortable with the somewhat unique world of kernel development by
separating the &amp;quot;on-boarding&amp;quot; process into focused manageable tasks.&lt;/p&gt;
&lt;p&gt;Sadly, The Eudyptula Challenge is no longer accepting new
applicants. However, if you wish to work on the tasks yourself, I've
published the 20 tasks I've managed to find along with the code I used
to &amp;quot;complete&amp;quot; them in a &lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula"&gt;git repo here&lt;/a&gt;.&lt;/p&gt;
&lt;div class="section" id="task-no-1"&gt;
&lt;h2&gt;Task No.1&lt;/h2&gt;
&lt;blockquote&gt;
&lt;p&gt;Write a Linux kernel module, and stand-alone Makefile, that when loaded
prints to the kernel debug log level, &amp;quot;Hello World!&amp;quot;  Be sure to make
the module be able to be unloaded as well.&lt;/p&gt;
&lt;p&gt;The Makefile should build the kernel module against the source for the
currently running kernel, or, use an environment variable to specify
what kernel tree to build it against.&lt;/p&gt;
&lt;p&gt;Please show proof of this module being built, and running, in your
kernel.  What this proof is is up to you, I'm sure you can come up with
something.  Also be sure to send the kernel module you wrote, along with
the Makefile you created to build the module.&lt;/p&gt;
&lt;p class="attribution"&gt;&amp;mdash;Little Penguin&lt;/p&gt;
&lt;/blockquote&gt;
&lt;/div&gt;
&lt;div class="section" id="what-is-a-module"&gt;
&lt;h2&gt;What Is A Module&lt;/h2&gt;
&lt;p&gt;A kernel module is piece of code designed to be loaded and unloaded on
demand by our kernels. For example, the device drivers for your
keyboard or a network card are a type of module. By separating the
kernel into individual software components, we can keep the overall
size of the kernel small, letting Linux fit into the smallest of
embedded systems. Some kernel modules, like the one we'll be building,
can even be installed without the need to recompile and reboot our
kernel, making upgrades easy, and saving us a lot of time.&lt;/p&gt;
&lt;p&gt;If you have access to a Linux machine, you can find the modules that
are currently loaded into the kernel by using the &lt;code&gt;lsmod&lt;/code&gt;
command, which gets its information from &lt;code&gt;/proc/modules&lt;/code&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="chiseling-a-cave-module"&gt;
&lt;h2&gt;Chiseling A Cave Module&lt;/h2&gt;
&lt;p&gt;Every kernel module must have at least two functions, one that will be
called when we install the module and another function to remove it
from the kernel. Back in the pre v2.3 era (&lt;a class="reference external" href="https://en.wikipedia.org/wiki/Linux_kernel_version_history"&gt;early 2000s&lt;/a&gt;) this
could only be done with a &amp;quot;start&amp;quot; function, called
&lt;code&gt;init_module()&lt;/code&gt; and an &amp;quot;end&amp;quot; function, called
&lt;code&gt;cleanup_module()&lt;/code&gt;. There are more modern (and preferred)
methods available to us today, however some developers still use
these, so it's a great starting point.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="cp"&gt;#include&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="cpf"&gt;&amp;lt;linux/kernel.h&amp;gt;&lt;/span&gt;&lt;span class="c1"&gt;  /* for KERN_DEBUG */&lt;/span&gt;
&lt;span class="cp"&gt;#include&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="cpf"&gt;&amp;lt;linux/module.h&amp;gt;&lt;/span&gt;&lt;span class="c1"&gt;  /* for all kernel modules */&lt;/span&gt;

&lt;span class="kt"&gt;int&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nf"&gt;init_module&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="kt"&gt;void&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;span class="p"&gt;{&lt;/span&gt;
&lt;span class="w"&gt;        &lt;/span&gt;&lt;span class="n"&gt;printk&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;KERN_DEBUG&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s"&gt;&amp;quot;Hello World.&lt;/span&gt;&lt;span class="se"&gt;\n&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;span class="w"&gt;        &lt;/span&gt;&lt;span class="k"&gt;return&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="mi"&gt;0&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="cm"&gt;/* init_module loaded successfully */&lt;/span&gt;
&lt;span class="p"&gt;}&lt;/span&gt;

&lt;span class="kt"&gt;void&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nf"&gt;cleanup_module&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="kt"&gt;void&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;span class="p"&gt;{&lt;/span&gt;
&lt;span class="w"&gt;        &lt;/span&gt;&lt;span class="n"&gt;printk&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;KERN_DEBUG&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s"&gt;&amp;quot;oh, the rest is silence.&lt;/span&gt;&lt;span class="se"&gt;\n&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;span class="p"&gt;}&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Typically &lt;code&gt;init_module()&lt;/code&gt; is used to register handlers or alter
some other part of the kernel for a device or something. The
&lt;code&gt;cleanup_module()&lt;/code&gt; will then undo those changes, allowing the
module to be removed safely from the kernel. Both of these functions
(as of version 5.7) can be found on line 75, as well as everything
else we need, in &lt;code&gt;linux/module.h&lt;/code&gt; of &lt;a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h?h=v5.7#n75"&gt;the source code&lt;/a&gt;.&lt;/p&gt;
&lt;div class="section" id="printk-printf"&gt;
&lt;h3&gt;printk() != printf()&lt;/h3&gt;
&lt;p&gt;To print &lt;code&gt;Hello World&lt;/code&gt; on &lt;em&gt;&amp;quot;the kernel debug log level&amp;quot;&lt;/em&gt;, we'll
need to use another, very old, function called &lt;code&gt;printk()&lt;/code&gt;. Unlike
the &lt;code&gt;printf()&lt;/code&gt; commonly used in userspace applications,
&lt;code&gt;printk()&lt;/code&gt; is not designed to communicate to the user (or say
hello to worlds). It's a logging mechanism used to give warnings and
to log messages. This is why each &lt;code&gt;printk()&lt;/code&gt; statement also
comes with a priority. There are currently 8 defined priorities we can
use ranging from &lt;code&gt;KERN_DEBUG&lt;/code&gt; to &lt;code&gt;KERN_EMERG&lt;/code&gt;. You can see
them all, and their definitions, currently (version 5.7) in
&lt;code&gt;linux/kern_levels.h&lt;/code&gt; in &lt;a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kern_levels.h?h=v5.7"&gt;the source code&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Pay attention to the single argument passed to &lt;code&gt;printk()&lt;/code&gt;. Looking
into the &lt;a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/printk/printk.c?h=v5.7#n2054"&gt;source code&lt;/a&gt;
shows that &lt;code&gt;printk(const char *ftm, ...)&lt;/code&gt; accepts only one
string, with space to pass extra arguments to format the string if
needed, for example, our &amp;quot;Hello World&amp;quot; statement from above, which
doesn't need formatting and therefore passes no extra arguments:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="n"&gt;printk&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;KERN_DEBUG&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s"&gt;&amp;quot;Hello World.&lt;/span&gt;&lt;span class="se"&gt;\n&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;The &lt;code&gt;KERN_DEBUG&lt;/code&gt; macro will expand to &lt;code&gt;&amp;quot;\001&amp;quot; &amp;quot;7&amp;quot;&lt;/code&gt;,
turning our statement into:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="n"&gt;printk&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="se"&gt;\001&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s"&gt;&amp;quot;7&amp;quot;&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s"&gt;&amp;quot;Hello World.&lt;/span&gt;&lt;span class="se"&gt;\n&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Our C lexer will then combine the adjacent string literals to produce
our formatted string for the kernel to log:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="n"&gt;printk&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="se"&gt;\001&lt;/span&gt;&lt;span class="s"&gt;7Hello World.&lt;/span&gt;&lt;span class="se"&gt;\n&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Even though &lt;code&gt;printk()&lt;/code&gt; is falling out of style with modern Linux
maintainers, as &lt;a class="reference internal" href="#pr-debug"&gt;we will see in later sections&lt;/a&gt;, there
is a lot more to read about how to work with &lt;code&gt;printk()&lt;/code&gt; and
format specifiers in the kernel in &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/core-api/printk-formats.html"&gt;the documentation here&lt;/a&gt;
if you're into that kind of stuff.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="making-a-kernel-module"&gt;
&lt;h2&gt;Making A Kernel Module&lt;/h2&gt;
&lt;p&gt;Much like how kernel modules are a little different than userspace
application modules, the Makefiles that compile the kernel are also a
bit different than Makefiles in userspace.&lt;/p&gt;
&lt;p&gt;Originally, as the Linux code-base grew, so did its Makefiles. As they
continued to grow in complexity, they eventually became a burden to
maintain. Fortunately a solution, called the &lt;em&gt;&amp;quot;kbuild system&amp;quot;&lt;/em&gt;, was
created and accepted into the kernel to help organize and simplify the
kernel's building process. If you are interested, there is an entire
section about the &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/kbuild/index.html"&gt;kbuild system in the
documentation.&lt;/a&gt;&lt;/p&gt;
&lt;div class="section" id="kbuild-makefile"&gt;
&lt;h3&gt;Kbuild Makefile&lt;/h3&gt;
&lt;p&gt;Just like Makefiles in userspace, we can start a Kbuild Makefile by
creating a new file called &lt;em&gt;…wait for it…&lt;/em&gt; &lt;code&gt;Makefile&lt;/code&gt; in the
same folder as our &lt;code&gt;hello-world.c&lt;/code&gt; module we made in &lt;a class="reference internal" href="#chiseling-a-cave-module"&gt;the
sections above&lt;/a&gt;.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ ls -l
total 8
-rw-rw-r-- 1 me us 903 Jul  5 00:00 hello-world.c
-rw-rw-r-- 1 me us 167 Jul  5 00:00 Makefile
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;We can alternatively use the name &lt;code&gt;Kbuild&lt;/code&gt; (not preferred) to
indicate to other developers that the Makefile is intended to run
using the kbuild system. However, while the &lt;code&gt;Kbuild&lt;/code&gt; name is not
preferred, interestingly, if both &lt;code&gt;Makefile&lt;/code&gt; and &lt;code&gt;Kbuild&lt;/code&gt;
files exist in the same directory the &lt;code&gt;Kbuild&lt;/code&gt; file will be
used. (&lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#the-kbuild-files"&gt;source&lt;/a&gt;)&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="goal-definitions"&gt;
&lt;h3&gt;Goal Definitions&lt;/h3&gt;
&lt;p&gt;The &amp;quot;heart&amp;quot; of the kbuild system uses lines called &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#goal-definitions"&gt;&amp;quot;goal definitions&amp;quot;&lt;/a&gt; to define all the various target files, special
compilation options, and any sub-directories to enter. When we compile
the kernel (with its thousands of Makefiles) the goal definitions are
collected and used to build all the various, documentation files,
modules, and other files we need for our particular kernel.&lt;/p&gt;
&lt;p&gt;The simplest Kbuild Makefile we can write for our module contains a
single line:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="nv"&gt;obj-m&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="o"&gt;+=&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;hello-world.o
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;&lt;code&gt;obj-m&lt;/code&gt; tells kbuild that our &lt;code&gt;hello-world.o&lt;/code&gt; object file
is a &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#loadable-module-goals-obj-m"&gt;loadable kernel module (LKM)&lt;/a&gt;
that can be loaded and unloaded at any time without needing to reboot
the kernel. This line will also tell the kbuild system to look for
files in our directory named &lt;code&gt;hello-world.c&lt;/code&gt; or
&lt;code&gt;hello-world.S&lt;/code&gt; to compile into the &lt;code&gt;hello-world.o&lt;/code&gt; object
file, before building the kernel object file &lt;code&gt;hello-world.ko&lt;/code&gt;
we'll use to load into our kernel.&lt;/p&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;There are a few different types of goal definitions, like
&lt;code&gt;obj-y&lt;/code&gt;, which defines build-in modules that are automatically
inserted into the kernel at boot-up (and not loadable by us). The
definitions for all the goal definitions can be found in the
&lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#goal-definitions"&gt;documentation here&lt;/a&gt; if you wish to learn more.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="convenience-targets"&gt;
&lt;h3&gt;Convenience Targets&lt;/h3&gt;
&lt;p&gt;For the pure convenience of it, we can add extra &lt;a class="reference external" href="https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html"&gt;phony targets&lt;/a&gt;
to our Kbuild Makefile to easily compile our module for the kernel
currently running on our computer, simplifying the task of compiling
our module down to just typing &lt;code&gt;make&lt;/code&gt; into our terminals:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="nf"&gt;all&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt;
&lt;span class="w"&gt;    &lt;/span&gt;&lt;span class="si"&gt;${&lt;/span&gt;&lt;span class="nv"&gt;MAKE&lt;/span&gt;&lt;span class="si"&gt;}&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;-C&lt;span class="w"&gt; &lt;/span&gt;/lib/modules/&lt;span class="k"&gt;$(&lt;/span&gt;shell&lt;span class="w"&gt; &lt;/span&gt;uname&lt;span class="w"&gt; &lt;/span&gt;-r&lt;span class="k"&gt;)&lt;/span&gt;/build&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nv"&gt;M&lt;/span&gt;&lt;span class="o"&gt;=&lt;/span&gt;&lt;span class="k"&gt;$(&lt;/span&gt;PWD&lt;span class="k"&gt;)&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;modules
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;And &lt;code&gt;make clean&lt;/code&gt; to clean up everything afterwards:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="nf"&gt;clean&lt;/span&gt;&lt;span class="o"&gt;:&lt;/span&gt;
&lt;span class="w"&gt;    &lt;/span&gt;&lt;span class="si"&gt;${&lt;/span&gt;&lt;span class="nv"&gt;MAKE&lt;/span&gt;&lt;span class="si"&gt;}&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;-C&lt;span class="w"&gt; &lt;/span&gt;/lib/modules/&lt;span class="k"&gt;$(&lt;/span&gt;shell&lt;span class="w"&gt; &lt;/span&gt;uname&lt;span class="w"&gt; &lt;/span&gt;-r&lt;span class="k"&gt;)&lt;/span&gt;/build&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nv"&gt;M&lt;/span&gt;&lt;span class="o"&gt;=&lt;/span&gt;&lt;span class="k"&gt;$(&lt;/span&gt;PWD&lt;span class="k"&gt;)&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;clean
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Both of these phony targets use the &lt;code&gt;-C&lt;/code&gt; option to move out of
our current directory and into our kernel's source directory. There
&lt;code&gt;make&lt;/code&gt; can find and use the top most kbuild Makefile, which
takes the &lt;code&gt;M&lt;/code&gt; option to locate the folder we are current
working in, and build the files defined using the &lt;code&gt;obj-m&lt;/code&gt; goal
definition &lt;a class="reference internal" href="#goal-definitions"&gt;we setup above&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="installing-a-kernel-module"&gt;
&lt;h2&gt;Installing A Kernel Module&lt;/h2&gt;
&lt;p&gt;Just as with our userspace applications, kernel modules need to be
compiled. Using the kbuild system, along with &lt;a class="reference internal" href="#convenience-targets"&gt;our convenience targets
above&lt;/a&gt;, we can compile our kernel module by
issuing the &lt;code&gt;make&lt;/code&gt; command, and if all goes well, you should see
an output similar to this:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ make
make -C /lib/modules/4.15.0-108-generic/build M=/home/me/src/eudyptula ...
/tasks/01 modules
make[1]: Entering directory &amp;#39;/usr/src/linux-headers-4.15.0-108-generic&amp;#39;
  CC [M]  /home/me/src/eudyptula/tasks/01/hello-world.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: modpost: missing MODULE_LICENSE() in /home/me/src/eudyptula ...
see include/linux/module.h for more information
  CC      /home/me/src/eudyptula/tasks/01/hello-world.mod.o
  LD [M]  /home/me/src/eudyptula/tasks/01/hello-world.ko
make[1]: Leaving directory &amp;#39;/usr/src/linux-headers-4.15.0-108-generic&amp;#39;
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;Ignore the &lt;code&gt;WARNING&lt;/code&gt; about missing &lt;code&gt;MODULE_LICENSE()&lt;/code&gt;
for now, it is a feature to warn users of non open-source code in
modules. We will address that issue in &lt;a class="reference internal" href="#kernel-taint"&gt;the following
sections.&lt;/a&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;The &lt;code&gt;.ko&lt;/code&gt; extension was introduced around kernel version 2.6 to
help differentiate between userspace object files and kernel object
files, which contain a &lt;code&gt;.modinfo&lt;/code&gt; section to hold extra metadata
information about the module. We can use the &lt;code&gt;modinfo&lt;/code&gt; command
to see and interpret the contents of the section:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ modinfo hello-world.ko
filename:       /home/me/src/eudyptula/tasks/01/hello-world.ko
srcversion:     18005133D4ECFCDD12928D8
depends:
retpoline:      Y
name:           hello_world
vermagic:       4.15.0-108-generic SMP mod_unload
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="section" id="installing-the-module"&gt;
&lt;h3&gt;Installing the Module&lt;/h3&gt;
&lt;p&gt;With our &lt;code&gt;hello-world.c&lt;/code&gt; module freshly compiled, we can insert
it into our kernel using the &lt;code&gt;insmod&lt;/code&gt; command as &lt;code&gt;root&lt;/code&gt; or
another user with &lt;code&gt;sudo&lt;/code&gt; privileges:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$&lt;span class="w"&gt; &lt;/span&gt;sudo&lt;span class="w"&gt; &lt;/span&gt;insmod&lt;span class="w"&gt; &lt;/span&gt;hello-world.ko
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="sidebar"&gt;
&lt;p class="first sidebar-title"&gt;NOTE:&lt;/p&gt;
&lt;p class="last"&gt;Don't worry about about kernel taint messages. We will address that
in &lt;a class="reference internal" href="#kernel-taint"&gt;the next section.&lt;/a&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;p&gt;&lt;strong&gt;Congratulations!&lt;/strong&gt;, you have created your first kernel module! A
quick inspection of the kernel's diagnostic messages, using
&lt;code&gt;dmesg&lt;/code&gt;, should show our &lt;code&gt;Hello World.&lt;/code&gt; message:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ dmesg | tail -1
[241745.247591] Hello World.
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="removing-the-module"&gt;
&lt;h3&gt;Removing the Module&lt;/h3&gt;
&lt;p&gt;After the well deserved pat-on-the-back and when you are ready to
continue, we can uninstall our module with the &lt;code&gt;rmmod&lt;/code&gt; command
as &lt;code&gt;root&lt;/code&gt; or someone with &lt;code&gt;sudo&lt;/code&gt; privileges:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ sudo rmmod hello_world
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;The only indication we've uninstalled our module will be in
&lt;code&gt;dmesg&lt;/code&gt; from our &lt;code&gt;printk()&lt;/code&gt; statement in the
&lt;code&gt;cleanup_module()&lt;/code&gt; function.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ dmesg | tail -1
[241751.401232] oh, the rest is silence.
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="kernel-taint"&gt;
&lt;h2&gt;Kernel Taint&lt;/h2&gt;
&lt;p&gt;There are plenty of ways &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html#table-for-decoding-tainted-state"&gt;we can taint our kernel&lt;/a&gt;.
Don't worry too much about this though, most of the time it is
completely fine to run a tainted kernel. When something happens that
could be important to an investigation later on, a kernel will mark
itself as &amp;quot;tainted&amp;quot;. Usually the event that caused the kernel to
become tainted is the problem being investigated.&lt;/p&gt;
&lt;p&gt;We can find our kernel's tainted state by reading our
&lt;code&gt;/proc/sys/kernel/tainted&lt;/code&gt; file. Every way we can taint our
kernels is assigned one bit in a bit-field, meaning any value other
than &lt;code&gt;0&lt;/code&gt; indicates our kernel is tainted. To decode the
bit-field values, we can use the &lt;code&gt;tools/debugging/kernel-chktaint&lt;/code&gt;
script found in &lt;a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/tools/debugging/kernel-chktaint"&gt;the source code&lt;/a&gt;,
to decode its meaning.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$ tools/debugging/kernel-chktaint
Kernel is &amp;quot;tainted&amp;quot; for the following reasons:
 * proprietary module was loaded (#0)
 * kernel issued warning (#9)
 * externally-built (&amp;#39;out-of-tree&amp;#39;) module was loaded  (#12)
 * unsigned module was loaded (#13)
For a more detailed explanation of the various taint flags see
 Documentation/admin-guide/tainted-kernels.rst in the the Linux kernel sources
 or https://kernel.org/doc/html/latest/admin-guide/tainted-kernels.html
Raw taint value as int/string: 12801/&amp;#39;P        W  OE    &amp;#39;
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="section" id="licensing-documentation"&gt;
&lt;h3&gt;Licensing &amp;amp; Documentation&lt;/h3&gt;
&lt;p&gt;One of the ways we can taint our kernels is by loading proprietary
modules or modules that use licenses not compatible with the General
Public License (GPL) (bit &lt;code&gt;0&lt;/code&gt; in &lt;a class="reference external" href="https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html#more-detailed-explanation-for-tainting"&gt;the tainting list&lt;/a&gt;). Modules
that don't use the &lt;code&gt;MODULE_LICENSE()&lt;/code&gt; macro will also be
considered proprietary and taint our kernel, if loaded (this is why we
saw &lt;a class="reference internal" href="#installing-the-module"&gt;the warning above&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;There are many documentation macros, defined in
&lt;code&gt;linux/module.h&lt;/code&gt;, some of the basics I added are:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="n"&gt;MODULE_LICENSE&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;MIT&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;span class="n"&gt;MODULE_AUTHOR&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;Bryan Brattlof &amp;lt;email@example.com&amp;gt;&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;span class="n"&gt;MODULE_DESCRIPTION&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;A Hello World Driver&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;span class="n"&gt;MODULE_SUPPORTED_DEVICE&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s"&gt;&amp;quot;testdevice&amp;quot;&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Once we add our module's license, author and other information to the
end of our &lt;code&gt;hello-world.c&lt;/code&gt; module, when we compile our module
again using &lt;code&gt;make&lt;/code&gt;, the &lt;code&gt;WARNING&lt;/code&gt; should be gone:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;$&lt;span class="w"&gt; &lt;/span&gt;make
make&lt;span class="w"&gt; &lt;/span&gt;-C&lt;span class="w"&gt; &lt;/span&gt;/lib/modules/4.15.0-108-generic/build&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="nv"&gt;M&lt;/span&gt;&lt;span class="o"&gt;=&lt;/span&gt;/home/me/src/eudyptula&lt;span class="w"&gt; &lt;/span&gt;...
make&lt;span class="o"&gt;[&lt;/span&gt;&lt;span class="m"&gt;1&lt;/span&gt;&lt;span class="o"&gt;]&lt;/span&gt;:&lt;span class="w"&gt; &lt;/span&gt;Entering&lt;span class="w"&gt; &lt;/span&gt;directory&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s1"&gt;&amp;#39;/usr/src/linux-headers-4.15.0-108-generic&amp;#39;&lt;/span&gt;
&lt;span class="w"&gt;  &lt;/span&gt;CC&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="o"&gt;[&lt;/span&gt;M&lt;span class="o"&gt;]&lt;/span&gt;&lt;span class="w"&gt;  &lt;/span&gt;/home/me/src/eudyptula/tasks/01/hello-world.o
&lt;span class="w"&gt;  &lt;/span&gt;Building&lt;span class="w"&gt; &lt;/span&gt;modules,&lt;span class="w"&gt; &lt;/span&gt;stage&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="m"&gt;2&lt;/span&gt;.
&lt;span class="w"&gt;  &lt;/span&gt;MODPOST&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="m"&gt;1&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;modules
&lt;span class="w"&gt;  &lt;/span&gt;CC&lt;span class="w"&gt;      &lt;/span&gt;/home/me/src/eudyptula/tasks/01/hello-world.mod.o
&lt;span class="w"&gt;  &lt;/span&gt;LD&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="o"&gt;[&lt;/span&gt;M&lt;span class="o"&gt;]&lt;/span&gt;&lt;span class="w"&gt;  &lt;/span&gt;/home/me/src/eudyptula/tasks/01/hello-world.ko
make&lt;span class="o"&gt;[&lt;/span&gt;&lt;span class="m"&gt;1&lt;/span&gt;&lt;span class="o"&gt;]&lt;/span&gt;:&lt;span class="w"&gt; &lt;/span&gt;Leaving&lt;span class="w"&gt; &lt;/span&gt;directory&lt;span class="w"&gt; &lt;/span&gt;&lt;span class="s1"&gt;&amp;#39;/usr/src/linux-headers-4.15.0-108-generic&amp;#39;&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;There where many reasons to add this system to the kernel. For
example, it gives developers a way to easily find who maintains a
module, describe what the module does, and what license the code is
protected with. It also provides an easy method to inform users when
they are using non open source software.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="updating-the-module"&gt;
&lt;h2&gt;Updating the Module&lt;/h2&gt;
&lt;p&gt;Everything in my notes, to this point, was needed to complete the 1&lt;sup&gt;st&lt;/sup&gt; task assigned to us by the Little Penguin. However, just
like with every software project, the Linux kernel is constantly
adding new features and adopting new coding styles, ensuring that
my notes will become obsolete as soon as I've writing them.&lt;/p&gt;
&lt;p&gt;With that said, the sections below, while not technically needed to
complete the task, are my notes on the macros and functions I saw in
the &lt;code&gt;drivers&lt;/code&gt; directory of the Linux source code that I found
particularly interesting. These functions are mostly stylistic changes
or they introduce functionality that improves efficiency and
modularity of the Linux kernel in some way.&lt;/p&gt;
&lt;div class="section" id="module-init-module-exit"&gt;
&lt;h3&gt;module_init() &amp;amp; module_exit()&lt;/h3&gt;
&lt;p&gt;Introduced in version 2.4 of the kernel, and defined in
&lt;code&gt;linux/init.h&lt;/code&gt; of the &lt;a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/init.h?h=v5.7"&gt;source code&lt;/a&gt;,
we can now rename our &amp;quot;start&amp;quot; and &amp;quot;end&amp;quot; functions to whatever we
wish. In this example, I've chosen to rename the &amp;quot;start&amp;quot; function to
&lt;code&gt;hello_world_init()&lt;/code&gt;&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="gd"&gt;-int init_module(void)&lt;/span&gt;
&lt;span class="gi"&gt;+static int __init hello_world_init(void)&lt;/span&gt;
&lt;span class="w"&gt; &lt;/span&gt;{
&lt;span class="w"&gt; &lt;/span&gt;        printk(KERN_DEBUG &amp;quot;Hello World.\n&amp;quot;);
&lt;span class="w"&gt; &lt;/span&gt;        return 0; /* init_module loaded successfully */
&lt;span class="w"&gt; &lt;/span&gt;}
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;And renamed the &amp;quot;exit&amp;quot; function &lt;code&gt;hello_world_exit()&lt;/code&gt;&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="gd"&gt;-void cleanup_module(void)&lt;/span&gt;
&lt;span class="gi"&gt;+static void __exit hello_world_exit(void)&lt;/span&gt;
&lt;span class="w"&gt; &lt;/span&gt;{
&lt;span class="w"&gt; &lt;/span&gt;        printk(KERN_DEBUG &amp;quot;oh, the rest is silence.\n&amp;quot;);
&lt;span class="w"&gt; &lt;/span&gt;}
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;The kernel will then use the &lt;code&gt;module_init()&lt;/code&gt; macro to find the
function to execute when the module is installed and
&lt;code&gt;module_exit()&lt;/code&gt; to find the function to cleanup before being
removed.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="n"&gt;module_init&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;hello_world_init&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;span class="n"&gt;module_exit&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="n"&gt;hello_world_exit&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;To avoid compiling issues, both the &lt;code&gt;module_init()&lt;/code&gt; and
&lt;code&gt;module_exit()&lt;/code&gt; macros must be defined below our newly named
&amp;quot;start&amp;quot; and &amp;quot;end&amp;quot; functions.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="init-exit"&gt;
&lt;h3&gt;__init &amp;amp; __exit&lt;/h3&gt;
&lt;p&gt;I also introduced two macros to our &amp;quot;start&amp;quot; and &amp;quot;end&amp;quot; functions &lt;a class="reference internal" href="#module-init-module-exit"&gt;above&lt;/a&gt; called &lt;code&gt;__init&lt;/code&gt; and
&lt;code&gt;__exit&lt;/code&gt;. These macros, defined in &lt;code&gt;linux/init.h&lt;/code&gt; of the
&lt;a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/init.h?h=v5.7#n48"&gt;source code&lt;/a&gt;, help reduce memory
used by the kernel depending on how the module is installed.&lt;/p&gt;
&lt;p&gt;For built-in modules, where our module cannot be removed from the
kernel without recompiling and restarting, the &lt;code&gt;__init&lt;/code&gt; keyword
will tell our C lexer to place our module's &amp;quot;start&amp;quot; function into a
special section inside the compiled kernel. After the module is loaded
and our &amp;quot;start&amp;quot; function has finished, the kernel will never have to
run the code again until reboot. So this special section can be freed,
saving memory.&lt;/p&gt;
&lt;p&gt;The same is true for the &lt;code&gt;__exit&lt;/code&gt; macro. For built-in modules,
the module cannot be removed from the kernel without recompiling and
restarting. So the kernel will never need to run our module's &amp;quot;exit&amp;quot;
function to safely remove it from the kernel. This means our C lexer
can safely omit our &amp;quot;exit&amp;quot; function from the compiled kernel.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="section" id="pr-debug"&gt;
&lt;h3&gt;pr_debug()&lt;/h3&gt;
&lt;p&gt;In the beginning there was &lt;code&gt;printk()&lt;/code&gt;, and the kernel's
diagnostic messages structure was formless. The lack of any format for
&lt;code&gt;printk()&lt;/code&gt; messages is one of a number of reasons why developers
are replacing &lt;code&gt;printk()&lt;/code&gt; statements with their newer
equivalents. Depending on what section of the kernel we are in, there
are newer functions that have some benefits for us.&lt;/p&gt;
&lt;p&gt;For example, the &lt;code&gt;pr_debug()&lt;/code&gt; function, which has the benefit of
being less syntactically verbose than &lt;code&gt;printk(KERN_DEBUG ...)&lt;/code&gt;
also allows us to take advantage of the &lt;a class="reference external" href="https://lwn.net/Articles/434833/"&gt;dynamic debugging interface&lt;/a&gt;, which gives developers a
uniform control interface for debugging kernel messages while avoiding
cluttering the kernel.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;static int __init hello_world_init(void)
&lt;span class="w"&gt; &lt;/span&gt;{
&lt;span class="gd"&gt;-    printk(KERN_DEBUG &amp;quot;Hello World.\n&amp;quot;);&lt;/span&gt;
&lt;span class="gi"&gt;+    pr_debug(&amp;quot;Hello World.\n&amp;quot;);&lt;/span&gt;
&lt;span class="w"&gt; &lt;/span&gt;    return 0; /* means init_module loaded successfully */
&lt;span class="w"&gt; &lt;/span&gt;}
&lt;/pre&gt;&lt;/div&gt;
&lt;div class="highlight"&gt;&lt;pre&gt;&lt;span&gt;&lt;/span&gt;&lt;span class="w"&gt; &lt;/span&gt;static void __exit hello_world_exit(void)
&lt;span class="w"&gt; &lt;/span&gt;{
&lt;span class="gd"&gt;-    printk(KERN_DEBUG &amp;quot;oh, the rest is silence.\n&amp;quot;);&lt;/span&gt;
&lt;span class="gi"&gt;+    pr_debug(&amp;quot;oh, the rest is silence.\n&amp;quot;);&lt;/span&gt;
&lt;span class="w"&gt; &lt;/span&gt;}
&lt;/pre&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class="section" id="wrapping-up"&gt;
&lt;h2&gt;Wrapping Up&lt;/h2&gt;
&lt;p&gt;If you made it here, all I can say is you are a very brave person, and
I'm glad my notes were able to help you in some way. If you see any
issues or have a question, please feel free to contact me, or better
yet &lt;a class="reference external" href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies"&gt;subscribe to the kernel newbies mailing list&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;For the next challenge, we will be building the Linux Kernel from scratch, as
well as installing and booting from it. If you want to work on this challenge
before you read my notes (recommended), I've published a copy of the challenges
in a &lt;a class="reference external" href="https://git.sr.ht/~bryanb/eudyptula"&gt;git repo here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Next&lt;/strong&gt;: My notes on &lt;a class="reference external" href="https://0x42.sh/building-the-linux-kernel/"&gt;How to build the Linux Kernel&lt;/a&gt; from scratch.&lt;/p&gt;
&lt;/div&gt;
</content><category term="Notes"/><category term="Eudyptula Challenge"/></entry></feed>