Specifications

CHAPTER 5. IMPLEMENTATION 37
ModuleOption mod_options[] = {
{"disable", "false", "disable=(true|false)"},
{"verbose", "true", "verbose=(true|false)"},
{NULL}
};
The following code shows an example of how a module creates the ModuleData structure.
The member options is a pointer to the array mod options.
ModuleData mod_data = {
.name = "Example Input Abstraction Layer Module",
.token = "example_module",
.version = "0.1",
.author = "Timo Hoenig",
.descr = "This is an example for an Input Abstraction Layer module.",
.options = mod_options,
.load = mod_load,
.unload = mod_unload,
};
Figure 5.4 visualizes the main components of a module and the daemon’s access to the
module’s data structures. As discussed, the module is required to define the ModuleOption
and ModuleData structures. Among others, the ModuleData structure provides references to
the array of ModuleOption structures and to the two functions responsible for loading and
unloading the module. Thus, the daemon only needs to obtain a pointer to ModuleData in
order to access all other data of the module. The invocation of mod get data() returns this
pointer to the daemon.
Input Abstraction Layer Module Input Abstraction Layer Daemon
ModuleData
Invocation
&ModuleData
mod_unload()
mod_load()
mod_get_data()ModuleOption
.options
.mod_load
.mod_unload
Module Loader
Figure 5.4: Input Abstraction Layer Module
Input Events
Once the modules are initialized, the daemon invokes the loading function load() of each
module. It is each module’s responsibility to verify whether the daemon has set the correct
configuration options. A subsequent call to load() has to initialize the kernel interface for
which the module is designed.