|
|||
|
|||
SRM - Documentation |
|||
|
^ SRM Documentation ^ API documentation - SRM Modules - Function Argument Handling |
Chapter 10. SRM Modules
The SRM system utilizes an extendible module system, where each extension is housed in a seperate directory of the source tree. This specific module subdirectory stores all the required resources for the module. Each of the module homes are located within the modules/ directory. The modules may be of two different types that can be used within the SRM system: 1) internal (i.e. standard), and 2) external (i.e. smxs). Internal modules are statically linked into the SRM daemon, while external modules are loaded at runtime. Initialization of all modules is completed upon system start-up. In this chapter the steps required to build such a module are explained, while looking at the SMXS module for SRM. This module is an external one. Build processEach modules home requires a corresponding config.m4. This file is processed by the autotools to create a Makefile for that module. An example config.m4 can be found in Appendix A. The config.m4 for a module is very similar to another module's, with minor changes for the module names and descriptions. An examination of the macros and their behaviors of the config.m4 follows. The first line contains the AC_MSG_CHECKING() function. This macro takes a string for a parameter, and will display that string for the user at ./configure time. The macro AC_ARG_ENABLE() takes multiple parameters. The first parameter identifies which module the configure script is to activate. The second parameter to the AC_ARG_ENABLE() macro is the enable flag text. This text is generally used during a ./configure process to allow an end user enable or disable a specific modules use. This text can also be displayed during a call to ./configure --help. It is not used for anything else. The third parameter to the AC_ARG_ENABLE() macro details the internal processes required to enable the module within the SRM process. The AC_MSG_RESULT() macro will display either yes or no. Depending upon the results of the AC_ARG_ENABLE() the module can be added to the module list via a call to the SRM_MODULE_ADD() macro. This macro can take two parameters, but requires only one. The first parameter is the name of the macro to be placed into the module list. The second, optional parameter, should only be used when creating an internal module. At which point it should be set to the value of static for this macro. Then additional libraries are checked which this module needs. The macro that checks for the availabilty of these libraries are located in another file, to reduce redundancy. This file is the acinclude.m4 file, found in the root tree of the SRM source. When all libraries are finally checked, the AC_DEFINE() macro will add an appropriate entry into the config.h file for the module. This will allow other sections of code to in the SRM project to access the modules functionality. If the module is static, an entry will also be put into the main/internal_functions.c file. |
||
| Prev: API documentation | Next: Module lay-out | ||
|
© 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by The Vulcan Logic Group |
|||