Big changes. Moved most of the chapters down to make room for "Process

Control" in chapter 6.

1 files changed, 379 insertions, 0 deletions

diff --git a/chapter_19.xml b/chapter_19.xml
new file mode 100644
index 0000000..bc49aed
--- /dev/null
+++ b/chapter_19.xml
@@ -0,0 +1,379 @@
+<?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>