diff options
| -rw-r--r-- | chapter_19.xml | 379 |
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> |