The magic behind it......

The modreq packet consists of two parts --- one is a set of kernel patches
that hook into every routine where things can fail due to a missing module.
Whenever this happens, a routine "activate_modreq" is called, which supplies
the information on what failed to a user level process through the
/dev/modreq device.

The user level process is the second part. It listens on the /dev/modreq
device for information on what kernel call failed, compares the info to its
config file, and if it knows what to do, takes appropriate action. In this
case, it then writes back a 1 to /dev/modreq, otherwise a 0.

The process in the kernel has meanwhile been waiting for the user level
process' reaction, and depending on it retries the kernel call or not. Of
course, there is only one retry, otherwise the possibility of an endless
loop would be far too likely.



The most interesting tidbit is how the "stop" script works --- looking at
it, it seem to do nothing but echo a message. But of course it looks like an
unknown executable format to the kernel, which promptly hands it on to the
modreq daemon --- which has a special check for this particular first four
bytes. Upon seeing them, it will tell the kernel it has no idea what to do,
and afterwards exit gracefully. The kernel will then treat the thing as a
shell script, having the little message output.


