1 Data used in the Module API

1.1 Types

olmod_error_t

An enumeration of errors that originate in a module. They are defined in include/olmod.h.

olmod_blackbox_t

A pointer to module defined data. It is the data that defines a particular instantiation of a module. The mainloop passes it back to the module when an operation is to be done for that instance (represented by the blackbox). It is essentially a void pointer. It's contents have no meaning to anything other than the module that it originated from.

olmod_arglist_t

During the module_inst and module_get calls to a module, an argument list is passed. It is essentially an array of void pointers. The mainloop will fill an argument list full of pointers to the appropriate data type(set out in the argument-type list.)

olmod_argtype_t

An enumeration of types, defined in include/olmod.h. The module definition includes two arrays of argument types (one static and one dynamic), the mainloop will use these arrays to figure out what type of data the module wants. The list(array) is stopped with a kEndList.

olmod_module_t

This is the module definition. It contains things like the nebuloid name, and pointers to the static and dynamic argument-type lists, as well as function pointers to the individual calls into the module.

1.2 Globals

object_global_overlord_table

This might be in need of a new name. Every package of modules will contain a global of this name. It is a list of olmod_module_t's, the overlord will look this table up and extract all nebuloid names to use in parsing the configuration file. When it needs to call into a module it will look up the functions to call in this table. This is the communication mechanism between the overlord and a module, without an entry in the table the overlord does not know a module exists.

This table is created automatically by the build system.