Tasks

This chapter provides descriptions of some common kernel related tasks.

General Kernel

The information in this section is a summary of the kernel-HOWTO

Kernel Compilation and Installation

This section briefly outlines the procedure for generating a bootable kernel image from source code.

  • Unpack the source code: tar xIvf linux-2.4.16 -C /usr/src.

  • make config and answer the list of questions with "y" to build an option into the kernel, "n" to leave it out and "m" to build it as a module. "?" gets you help on most options.

  • Review the .config file found in the top level source directory and change as necessary.

  • make bzImage modules

  • Become root and make modules_install

  • Copy System.map to /boot/System-2.4.14.map

  • Copy ~/arch/i386/boot/bzImage to /boot/bzImage-2.4.14 (or whatever kernel version you are using).

  • Edit /etc/lilo.conf and add a new entry for your new image, using one of the existing ones as a template. Keep at least one of the old entries in case the new kernel does not boot.

  • Run /sbin/lilo, as root.

  • Shutdown and reboot, be sure to select your new kernel at the boot loader prompt, if you did not set it up to boot by default.

  • Enjoy the new kernel!

Note that you can set the default kernel for the next reboot only by re-running lilo with the -R switch followed by the appropriate image label.

General Hacking

This section is still very incomplete...

Print messages to kernel logs

The printk() function can be used to output tracing/debugging info to the kernel logs.

Creating a new module

See forthcoming revised Linux Module Programming Guide.

Configuration options

The easiest way to add boot time options is to find the existing kernel option that matches your requirements most closely and copy that. Take a look at and edit the Config.in file in the associated directory. Then surround your option specific code with inclusion guards.

Boot time parameters

It is possible to pass information to the kernel at boot time in the form of command line options. For information about the current list of options, see ~/Documentation/kernel-parameters.txt and the Linux BootPrompt-HOWTO.

Some drivers make use of this facility to set base addresses where hardware auto-detection is not possible or not implemented. Boot time parameters are especially useful when drivers or features are compiled into the kernel and not as a module, where options can be given when the module is loaded.

At version 2.3.13 the kernel initialisation code changed significantly for the better. Previously, the initialisation code was covered in #ifdef SOME_CONFIG_OPTION statements, to ensure only the required initialisation code is compiled into the final image. Now a different approach is taken, known as "init calls", where the initialisation functions are registered and stored in a special location in the ELF executable format. At system start up, each of the registered functions is called in turn (although it is not possible to specify the order of execution, so some #ifdef statements remain).

A similar approach is used to parse boot time options. To associate a particular boot time string with its own handling function, a call is made to __setup(). This could be done from ~/init/main.c.

For example, to add support for a command line option uptime, which sets initial uptime to a specified number of jiffies:

static int __init riguptime(char *line){
	jiffies = simple_strtol(line, (char **)(line + sizeof(line)), (unsigned int)10);
	return 0;
}

__setup("uptime=", riguptime);
			

So if the kernel was booted with uptime=12345 as a command line option, *line (passed to riguptime()) would point to a null-terminated string containing "12345". This string is converted to a value of type long by the simple_strtol() macro.

Adding a system call

It should be possible to do just about everything you could need to without doing this. Really.

OK so you still want to? ("Don't try this at home kids!")

See this tutorial (but needs adapting for 2.4.x).

Add a /proc entry

One of the ways to avoid adding another system call is to use the /proc interface. This section will describe a simple example.

Bug Hunting

The scenario: You have just upgraded to the latest and greatest kernel, only to find it Oopses on your machine. The Linux-Kernel mailing list gets several posts a day along the lines of "2.4.xx" oopses/fails to boot. What is wrong?" Most of these posts never get answered, sometimes even the ones with a little more information (including the dreaded .config file) get no response.

Generally, the posts that do get answered and resolved are those where the user has done some "home work" and is some way towards locating the problem.

So where do you start with tracking down the problem?

For now, see Documentation/BUG-HUNTING until this section gets finished.