Modules are dynamically-loaded pieces of the kernel: once in place they have no restrictions on their behaviour. In 2.3.13 the module source interface was improved to make it easy to write code which could operate either as a module or compiled into the kernel; these calls are always valid even if the code is not compiled as a module.
This macro defines a special function to be called at module insertion time (if the file is compiled as a module), or at boot time. A module can take arguments using the MODULE_PARM macro. It can return a negative error number to cause module loading to fail (unfortunately, this has no effect if the module is compiled into the kernel). This is called in user context, with interrupts enabled, and the kernel lock held, so it can sleep.
This macro defines the function to be called at module removal time (or never, in the case of the file compiled into the kernel). It will only be called if the module usage count has reached zero. This function can also sleep.
This manipulates the module usage count, to protect against removal (a module also can't be removed if another module uses one of its exported symbols: see below). Every reference to the module from usercontext should be reflected by this counter (e.g. for every datastructure or socket). Interrupt functions don't need to care, although there are some subtle races on module unloading on SMP, if you e.g. don't explicitely remove the interrupt or del_timer() the timer early in exit.
In 2.2 kernel, modules delcared two functions called init_module() and cleanup_module(), which were called at module init and exit.