The module programming book can be found online at http://www.ibiblio.org/mdw/LDP/lkmpg/mpg.html.

Notes about the book

There are three reasons to have modules.

Modules can implement a device driver.  They cannot implement a device driver needed for boot.  There is a standard deamon that loads and unloads device driver modules as needed, but it won't work for our device driver modules because we haven't configured the deamon for our devices.  We could, it would be easy, but for debugging purposes it's best to do this stuff by hand.

OR

Modules can replace functions of the kernel with a new function of the same name.  These functions can be a replacement for the previous function.  For example, one could add to the kernel a new "schedule", and change which process gets run when.  These functions can add to previous functions.  For example, one could add the to the open system call a check to see if Andy was the user.  It might reject all of Andy's opens, but call the normal function when it was sure the opener was not Andy.

OR

Modules can be distributed as just the compiled code.  If you want to add something to the Linux kernel, you normally have to ship the source code to Linus.  If you make a module of your code, then you can just hand the compiled code to people who want to use your new functionality, and hide the source code from them.  Versioning makes this hard, however.

Modules are version specific.   Modules need to access kernel global variables.  But different versions of the kernel have different global variables in different places.   There are two ways to handle this.
Modules are version specific.  Each module contains the version number of the kernel it was compiled for.  Modules will only load for that version.

OR

The kernel and the module were compiled with the "Modversion" option.  When loading, the loading utility checks wether this modules has any incompatabilities with this kernel.  It loads or error appropriately.

Object Files
An object file contains two things.  It contains the machine language result of compiling source code.  Further, it contains relocation information.  Relocation information is just a list of every variable and function, and where that is stored.  Object files are typically name foo.o
Modules
Are not programs.  You cannot RUN a module.  Instead, modules are object files that are added to an already running kernel.  When the module is loaded or unloaded, special functions are called.  At these times your code can act.  Further, it can modify the kernel such that the modules other functions are run at other times.
Linking
Linking is the act of taking one or more object files, and either making a bigger object file that is the union of the source files, or making an executable that is a program that can be run containing the functions and variables from the source object files.
Makefiles are cool
A makefile contains dependency information needed to compile a file.  For example, if you need the foo.c and foo.h file to create the foo.o object module, then the makefile will contain that data.  The needed files (foo.c and foo.h) are the SOURCE.  The resulting file (foo.o) is the target.  Further, makefiles contain command information.  For example, if you need to run "gcc -c foo.c" to create the foo.o file, the makefile will say that.

The make utility reads makefiles, and runs the fewest number of commands to generate the target based on the dependencies.  The make command can be used to generate any target in the makefile, but the default is the first target listed.

Makefile syntax is PICKY.  The thing that seperates targets from sources are TABS, and not spaces.

Here is a sample makefile
foo.o:    foo.c foo.h
          gcc -c foo.c