chapter_19.xml

<?xml version="1.0"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "/usr/share/xml/docbook/xml-dtd-4.5/docbookx.dtd">

<chapter>
<title>The Linux Kernel</title>

<section>
<title>What Does the Kernel Do?</title>

<para>
You've probably heard people talking about compiling the kernel or
building a kernel, but what exactly is the kernel and what does it do?
The kernel is the center of your computer. It is the foundation for the
entire operating system. The kernel acts as a bridge between the
hardware and the applications. This means that the kernel is (usually)
the sole piece of software responsible for ordering around the hardware
components of your computer. It is the kernel that instructs the hard
drive to search for a certain data stream. It is the kernel that
instructs your network card to transmit rapid changes in voltage. The
kernel also listens to hardware as well. When the network card detects
a remote computer sending information, it forwards that information to
the kernel. This makes the kernel both the single most important piece
of software on your computer and the most complex.
</para>

</section>

<section>
<title>Working with Modules</title>

<para>
The complexity of a modern linux kernel is staggering. The source code
for the kernel weighs in at nearly 400MB uncompressed. There are
thousands of developers, hundreds of options, and if everything were
built together, the kernel would soon pass 100MB in size itself. In
order to keep the size of the kernel down (as well as the amount of RAM
needed for the kernel), most of the kernel options are built as
modules. You can think of these modules as device drivers which can be
inserted or removed from a running kernel at will. In truth, many of
them aren't device drivers at all, but contain support for things such
as network protocols, security measures, and even filesystems. In
short, nearly any piece of the linux kernel can be built as a loadable
module.
</para>

<para>
It's important to realize that Slackware will automatically handle
loading most modules for you. When your system boots,
<application>udevd</application>(8) is started and begins to probe your
system's hardware. For each device it finds, it loads the proper module
and created a device node in <filename>/dev</filename>. This usually
means that you will not need to load any modules in order to use your
computer, but occasionally this is necessary.
</para>

<para>
So what modules are currently loaded on your computer and how do we
load and unload them? Fortunately we have a full suite of tools for
handling this. As you might have guessed, the tool for listing modules
is <application>lsmod</application>(8).
</para>

<screen><prompt>darkstar:~# </prompt><userinput>lsmod</userinput>
Module                  Size  Used by
nls_utf8                1952  1 
cifs                  240600  2 
i915                  168584  2 
drm                   168128  3 i915
i2c_algo_bit            6468  1 i915
tun                    12740  1 
... many more lines ommitted ...
</screen>

<para>
In addition to showing you what modules are loaded, it displays the
size of each module and tells you what other modules are using it.
</para>

<para>
There are two applications for loading modules:
<application>insmod</application>(8) and
<application>modprobe</application>(8). Both will load modules and
report any errors (such as loading a module for a device that isn't
present in your system), but <application>modprobe</application> is
preferred because it can load any module dependencies. Using either is
straight-forward.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>insmod ext3</userinput>
<prompt>darkstar:~# </prompt><userinput>modprobe ext4</userinput>
<prompt>darkstar:~# </prompt><userinput>lsmod | grep ext</userinput>
ext4                  239928  1 
jbd2                   59088  1 ext4
crc16                   1984  1 ext4
ext3                  139408  0 
jbd                    48520  1 ext3
mbcache                 8068  2 ext4,ext3
</screen>

<para>
Removing modules can be a tricky process, and once again we have two
programs for removing them: <application>rmmod</application>(8) and
<application>modprobe</application>.  In order to remove a module with
modprobe, you'll need to use the <arg>-r</arg> argument.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>rmmod ext3</userinput>
<prompt>darkstar:~# </prompt><userinput>modprobe -r ext4</userinput>
<prompt>darkstar:~# </prompt><userinput>lsmod | grep ext</userinput>
</screen>

</section>

<section>
<title>Compiling A Kernel and Why to do So</title>

<para>
Most Slackware users will never need to compile a kernel. The huge and
generic kernels contain virtually all the support you will need.
However, some users may need to compile a kernel. If your computer
contains bleeding edge hardware, a newer kernel may offer improved
support. Sometimes a kernel patch my be available that corrects a
problem you are experiencing. In these cases a kernel compile is
probably warranted.  Users who simply want the latest and greatest
version or who believe using a custom compiled kernel will give them
greater performance can certainly upgrade, but are unlikely to notice
any major changes. If you still think compiling your own kernel is
something you want or need to do, this section should walk you through
the many steps.
Compiling and installing a kernel is not that difficult, but there are
a number of mistakes that can be made along the way, many of which can
prevent your computer from booting and cause major frustration.
</para>

<para>
The first step is ensuring you have the kernel source code installed on
your system.  The kernel source package is included in the "k" disk set
in the Slackware installer, or you can download another version from
<ulink url="http://www.kernel.org/">http://www.kernel.org/</ulink>.
Traditionally, the kernel source is located in
<filename>/usr/src/linux</filename>, a symbolic link that points to the
specific kernel release used, but this is by no means set in stone. You
can place the kernel source code virtually anywhere without
encountering any problems.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>ls -l /usr/src</userinput>
lrwxrwxrwx  1 root root   14 2009-07-22 19:59 linux -> linux-2.6.29.6/
drwxr-xr-x 23 root root 4096 2010-03-17 19:00 linux-2.6.29.6/
</screen>

<para>
The most difficult part of any kernel compile is the kernel
configuration. There are hundreds of options, many of which can
optionally be compiled into modules. This means there are thousands of
ways to configure a kernel. Fortunately, there are a few handy tricks
that can keep you from running into too much trouble.  The kernel
configuration file is <filename>.config</filename>. If you are very
brave, you can manually edit this file with a text editor, but I highly
recommend you use the kernel's built-in tools for manipulating
<filename>.config</filename>.
</para>

<para>
Unless you are very familiar with configuring kernels, you should
always start with a solid base configuration and modify it. This
prevents you from skipping an important option that might force you to
compile the kernel again and again until you get it right.  The best
kernel <filename>.config</filename> files to start with are those used
by Slackware's default kernels. You can find them on your Slackware
install disks or at your favorite mirror in the
<filename>kernels/</filename> directory.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>mount /mnt/cdrom</userinput>
<prompt>darkstar:~# </prompt><userinput>cd /mnt/cdrom/kernels</userinput>
<prompt>darkstar:/mnt/cdrom/kernels# </prompt><userinput>ls</userinput>
VERSIONS.TXT  huge.s/  generic.s/ speakup.s/
<prompt>darkstar:/mnt/cdrom/kernels# </prompt><userinput>ls genric.s</userinput>
System.map.gz  bzImage  config
</screen>

<para>
You can replace the default <filename>.config</filename> file easily by
copying or downloading the <filename>config</filename> file for the
kernel you wish to use as a base. Here I am using Slackware's
recommended generic.s kernel for a base, but you may wish to use the
huge.s config file. The generic kernel builds more things as modules
and thus creates a smaller kernel image, but it usually requires the
use of an initrd.
</para>

<screen><prompt>darkstar:/mnt/cdrom/kernels# </prompt><userinput>cp generic.s/config /usr/src/linux/.config</userinput>
</screen>

<note><para>
The Slackware kernel file lacks the "dot" while the kernel
file includes it. If you forget, or simply copy the
<filename>config</filename> to <filename>/usr/src</filename> whatever
<filename>.config</filename> file was already present will be used
instead.
</para></note>

<para>
If you want to use the configuration for the currently running kernel
as your base, you may be able to locate it at
<filename>/proc/config.gz</filename>. This is a special kernel-related
file that includes the entire kernel configuration in a compressed
format and requires that your kernel was built to support it.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>zcat /proc/config.gz > /usr/src/linux/.config</userinput>
</screen>

<para>
Now that we've created a solid base configuration, it's time to make
any configuration changes we want. The entire kernel build process from
configuration to compilation is performed with the
<application>make</application>(1) command and special arguments to it.
Each argument performs a different function.
</para>

<para>
If you are upgrading to a newer kernel release, you will definitely
want to use the <arg>oldconfig</arg> argument. This will step through
your base <filename>.config</filename> and look for missing elements
that usually indicates that the new kernel release contains additional
options. Since options are added at virtually every kernel release,
this is generally a good thing to do.
</para>

<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make oldconfig</userinput>
scripts/kconfig/conf -o arch/x86/Kconfig
*
* Restart config...
*
*
* File systems
*
Second extended fs support (EXT2_FS) [M/n/y/?] m
  Ext2 extended attributes (EXT2_FS_XATTR) [N/y/?] n
  Ext2 execute in place support (EXT2_FS_XIP) [N/y/?] n
Ext3 journalling file system support (EXT3_FS) [M/n/y/?] m
  Ext3 extended attributes (EXT3_FS_XATTR) [Y/n/?] y
    Ext3 POSIX Access Control Lists (EXT3_FS_POSIX_ACL) [Y/n/?] y
    Ext3 Security Labels (EXT3_FS_SECURITY) [Y/n/?] y
The Extended 4 (ext4) filesystem (EXT4_FS) [N/m/y/?] (NEW) <userinput>m</userinput>
</screen>

<para>
Here you can see that I the new kernel I am compiling has added support
for a new filesystem: ext4. <arg>oldconfig</arg> has gone through my
original configuration, kept all the old options exactly as they were
set, and prompted me on what to do with new options. Typically it is
save to choose the default option, but you may wish change this.
<arg>oldconfig</arg> is a very handy tool for presenting you with only
new configuration options, making it ideal for users who simply have to
try out the latest kernel release.
</para>

<para>
For more serious configuration tasks, there are a multitude of options.
The linux kernel can be configured in three primary ways. The first is
<arg>config</arg>, which will step through each and every option one by
one and ask what you would like to do. This is so tedious that hardly
anyone ever uses it anymore.
</para>

<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make config</userinput>
scripts/kconfig/conf arch/x86/Kconfig
*
* Linux Kernel Configuration
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?] <userinput>Y</userinput>
Local version - append to kernel release (LOCALVERSION) [] <userinput>-test</userinput>
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] <userinput>n</userinput>
Support for paging of anonymous memory (swap) (SWAP) [Y/n/?]
</screen>

<para>
Fortunately, there are two much easier ways to configure your kernel,
<arg>menuconfig</arg> and <arg>xconfig</arg>. Both of these create a
menu-driven program that lets you select and de-select options without
having to step through each one. <arg>menuconfig</arg> is the most
commonly used method, and the one I recommend. <arg>xconfig</arg> is
only useful if you are attempting to compile the kernel from a
graphical user interface within <application>X</application>. Both are
so similar however, that we are only going to document
<arg>menuconfig</arg>.
</para>

<para>
Running <userinput>make menuconfig</userinput> from a terminal will
present you with the friendly curses-driven interface you see below.
Each kernel section is given its own submenu, and you can navigate with
the arrow keys.
</para>

<imagedata fileref="img/make-menuconfig-w.png" format="PNG"/>

<warning><para>
If you are compiling a kernel that is the same release as the stock
Slackware kernel, you must set the "Local version" option. This is
found on the "General setup" submenu. Failure to set this will result
in your kernel compile over-writing all the modules used by the stock
kernels. This can quickly render your system unbootable.
</para></warning>

<para>
Once you've finished configuring the kernel, it's time to begin
compiling it. There are many different methods for this, but the most
reliable is to use <arg>bzImage</arg>. When you pass this argument to
<application>make</application>, the kernel compilation will begin and
you will see lots of data scroll through the terminal until either the
compile process is complete or a fatal error is encountered.
</para>

<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make bzImage</userinput>
scripts/kconfig/conf -s arch/x86/Kconfig
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-x86
  CALL    scripts/checksyscalls.sh
  CC      scripts/mod/empty.o
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
... many hundreds of lines ommitted ...
</screen>

<para>
If the process ends in an error, you should check your kernel
configuration first. Compile errors are usually caused by a fault
<filename>.config</filename> file. Assuming everything went alright,
we're still not entirely finished, as we need to build the modules.
</para>

<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>make modules</userinput>
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-x86
  CALL    scripts/checksyscalls.sh
  HOSTCC  scripts/mod/file2alias.o
... many thousands of lines omitted ...
</screen>

<para>
If both the kernel and the modules compiles finished sucessfully, we're
ready to install them. The kernel image needs to be copied into a safe
location, typically the <filename>/boot</filename> directory, and you
should give it a unique name to avoid overwriting any other kernel
images located there. Traditionaly kernel images are named
<filename>vmlinuz</filename> with the kernel release and local version
appended.
</para>

<screen><prompt>darkstar:/usr/src/linux# </prompt><userinput>cat arch/x86/boot/bzImage > /boot/vmlinuz-release_number-local_version</userinput>
<prompt>darkstar:/usr/src/linux# </prompt><userinput>make modules_install</userinput>
</screen>

<para>
Once these steps have been completed, you will have a new kernel image
located under <filename>/boot</filename> and a new kernel modules
directory under <filename>/lib/modules</filename>. In order to use
this new kernel, you will need to edit <filename>lilo.conf</filename>,
create an initrd for it (only if you need to load one or more of this
kernel's modules to boot), and run <application>lilo</application> to
update the boot loader. When you reboot, if all went according to plan,
you should have an option to boot with your newly compiled kernel. If
something went wrong, you may be spending some time fixing the problem.
</para>

</section>

</chapter>