For Linux Loadable Kernel Modules (LKMs), see also  kernel-modules-hooks-and-rootkits.txt

1. Modules in Linux and Solaris/Illumos.

Linux LKMs are simply C code that will be executed in the kernel
context.  Just like main(), by convention, is called when a userland
program is exec-ed, init_module() is called when an LKM is "loaded"
(either from the command line with insmod or modprobe commands, or
automatically, in response to some system bus event, if
configured). Loading actually means first allocating some memory pages
in the kernel space, copying the binary code there, and then linking
that code with the rest of the kernel as needed. In particular, all
kernel functions called from the module's binary code will be linked
at that time; unlike userland dynamic linkers, LKM linking is not
"lazy".

Earlier (2.0-2.4) versions of the Linux kernel placed very few demands
on an object file to be inserted into the kernel.  Later versions
introduced "magic" version numbers (partly to prevent novice users
from loading modules that might be binary-incompatible with the kernel
and crash it, partly to discourage vendors from shipping binary-only
modules). This versioning is explained here:
          http://www.phrack.org/issues.html?issue=68&id=11

For the official developer documentation on LKMs, see
          http://www.tldp.org/HOWTO/Module-HOWTO/

2. LKMs vs Kprobes

Prior to Kprobes, LKMs were the only supported interface for injecting (compiled)
C code into the kernel, to run in kernel context. Kprobes changed that; 
the following Phrack article describes the internals and use of Kprobes:
          http://www.phrack.org/issues.html?issue=67&id=6

3. Modules in OpenSolaris/Illumos

Modules in OpenSolaris/Illumos are primarily meant to serve as device
drivers. Moreover, Solaris explicitly specifies the functions and
interfaces to be used by drivers, the Driver Development Kit (DDK) --
unlike Linux, which allows an LKM to use any public kernel symbol. 

Hence Solaris modules must, in their _init() entry point, fill several
tables worth of data regarding the device file (in /dev or /devices) that
the module provides the driver to, including various functions/methods
pointer tables; without these, the module load will not succeed.

A hands-on intro to writing a "dummy device" Illumos driver: 
http://www.cs.dartmouth.edu/~sergey/cs258/2009/Device_Drivers_Hands_on_Lab.pdf

More in-depth (regarding actual device drivers):
http://www.cs.dartmouth.edu/~sergey/cs258/2010/KCA1_Sonnenschein_Drivers.pdf

3. Miscellaneous.

If you are curious about MacOS X kernel rootkits, Phrack 66:16 is here to help:
http://www.phrack.org/issues.html?issue=66&id=16 ! 

Note that MacOS modules are called "extensions".