/**
 * @page modules The Module System
 *
 * One major component of pbbuttonsd is the module system. The daemon
 * does a lot of mostly independent jobs like changing the master volume
 * or setting the display brightness. Volume and brightness have nothing
 * to do with each other except that Their change is triggered by some
 * input data comming from the Input Manager. This makes it easy to put
 * different functionality in seperate modules and makes it possible to
 * extend the system with new modules or exchange single ones.
 *
 * One main goal of the concept is to divide hardware or machine dependent
 * functions from non hardware or machine dependent and put all this into
 * layers. This would make it possible to adapt pbbuttonsd to a new machine
 * simply by replacing the machine layer (module).
 *
 * The modules are as independent and free as possible and are free to do
 * anything necessary to do their job. The program framework will only
 * provide some useful tools to simplify things every module needs like an
 * IPC interface to the clients or similar.
 * 
 * Now have a look to the modules and their interaction:
 * <img src="../images/modules.png">
 *
 * Modules directly above the Kernel are hardware or machine dependent
 * modules. They are modules Pri1 (priority one). The modules in the next
 * row are function modules and Pri2 (priority 2). System services such as
 * the input manager and the IPC system are Pri0 (priority 0). The priority
 * tells us the sequence which is used to initialise the modules: First Pri0
 * modules followed by Pri1 and last but not least Pri2. It tells us further
 * that a Pri1 module can't ask a Pri2 module for data during startup because
 * it wouldn't be initialised at this time.
 *
 * Modules with the same colour do identical jobs so only one of them would
 * be active in PBButtons. The picture shows just enough different modules to
 * make the idea clear. We could think of much more different modules.
 *
 * <h3>The Module API</h3>
 *
 * To implement a new module only four functions have to be implemented:
 *  @li int init()
 *  @li void exit()
 *  @li void query(struct tagitem *taglist)
 *  @li void config(struct tagitem *taglist)
 *
 * The function <b>init()</b> will be called during startup and should do any
 * task that is necessary to make the module operate. Pbbuttons expects that
 * each module is able to work properly and respond correctly to requests after
 * this function has returned sucessfully.
 * 
 * If something went wrong this function may return FALSE. This will imedeately
 * terminate pbbuttonsd and should only be returned on grave errors. On less
 * important errors, the module should print a warning and disable itself.
 *
 * The function <b>exit()</b> will be called just before pbbuttonsd terminates.
 * It should close all file handles and free all ressources allocated by the
 * module.
 *
 * The functions <b>query()</b> and <b>config()</b> are used to interchange data
 * with this module. Config() is called if a client or another module wants to
 * change a property of this module and query() is called whenever someone asks
 * for a certain property.
 *
 * The mechanism to exchange information is described in
 * @subpage taglist "Taglists".
 */
