Classe LINUXCONF_MODULE, vue publique
#Specification: module / compatibility ([module.cc,780])
A module is compiled using some APIs in linuxconf. To make sure a given module is compatible with a given API revision, each module defines an integer global variable which contains the API version. This is done with the MODULE_DEFINE_VERSION macro. Each module must defined a unique symbol so RTLD_GLOBAL may be used. So symbol is built by appending the module name to MODULE_SYMBOL_VERSION.
#Specification: module / dlopen / RTLD_LAZY ([module.cc,732])
Linuxconf is loading modules with dlopen flag RTLD_LAZY. Some modules are using dlopen() internally and require that their name space become visible to the sub-modules. As far as we know, this is only needed for exceptional modules (redhat and conectiva using the libpam library), but might turn out to the useful for other in the future (especially module providing bindings to various interpreted language). The case known is when a module is linked with a special library which itself does dlopen() at some point. The libpam library does that. With RTLD_LAZY flag, the various symbols of the module are not exported, so the "sub-modules" can't be loaded (the various pam_xxx.so modules). This RTLD_GLOBAL flag has two disadvantages (maybe)
So for now, we are using RTLD_LAZY for all module except the redhat and conectiva modules. Note that the exception is handled in linuxconf code. Module requiring RTLD_GLOBAL are probably exceptional anyway.
-It is probably a little slower (as it imply RTLD_NOW). -Two modules may not defined the same symbol twice. This might be annoying as two independant modules author may define too global function with the same name and the problem will only occurs when both modules are used at the same time. Further the behavior of the dynamic linker is pretty weird: It does not complain but screw things...
#Specification: module / path / default path ([module.cc,446])
If a module is define only with its name, linuxconf assume it is located in /usr/lib/linuxconf/lib
#Specification: module / selection ([module.cc,457])
Linuxconf will pick the module with the largest version where a version is defined as x.y.z.w and where the missing suffixes are replaced by 0. So
1.9 is 126.96.36.199
#Specification: modules / activation ([module.cc,711])
Whenever we accept the change in the module list, linuxconf will try to load and activate a module. Doing a dlopen on a module twice is not a problem. Unloading a module is not really possible during a session, so removal or desactivation of a module will take effect at the next session.
#Specification: modules / elf only ([module.cc,2])
Module support in linuxconf only work for ELF systems.
#Specification: modules / revision management ([module.cc,534])
Linuxconf's modules follow a strict numbering scheme to avoid strange incompatibilities. For each linuxconf version, linuxconf expect a module using the same version number. Module may use a seperate number to differentiate internal releases. Linuxconf will always used the highest internal release. For example, given a module "/var/project/dummy", linuxconf 1.6 will look for /var/project/dummy.so.1.6.0. If it exist, linuxconf will look for /var/project/dummy.so.1.6.1 and so on. It will use the highest found. To give some flexibility to the user, linuxconf allows one to specify the full path of the module. So linuxconf first try to open this file. If it exist, it is believe to be the module. If not, the extension .so.LINUXCONF_REV.SUBREV is tried. The idea is to let someone say "Use /var/project/dummy.so.1.7.4" just to see if it is better than 1.7.5 for example.
PUBLIC LINUXCONF_MODULE::LINUXCONF_MODULE( const char *_name)
Let the module add its own option to one menu. The "context" let the module identify which dialog it is The module is not forced to add options to the menu.
PUBLIC VIRTUAL void LINUXCONF_MODULE::setmenu( DIALOG&dia, MENU_CONTEXT ctx)
PUBLIC VIRTUAL void LINUXCONF_MODULE::setmenu( DIALOG&dia, const char *menuid)
PUBLIC VIRTUAL void LINUXCONF_MODULE::setmenu( M_DIALOG&, MENU_CONTEXT)
PUBLIC VIRTUAL void LINUXCONF_MODULE::setmenu( M_DIALOG&, const char *)
Let the module take control for some html query.
PUBLIC VIRTUAL int LINUXCONF_MODULE::dohtml( const char *)
Check if the user has selected one menu option related to this module Do nothing most of the time.
PUBLIC VIRTUAL int LINUXCONF_MODULE::domenu( MENU_CONTEXT, // context const char *) // key
Check if the user has selected one menu option related to this module Do nothing most of the time. Variation allowing any menu to be enhance (menus in modules for one)
PUBLIC VIRTUAL int LINUXCONF_MODULE::domenu( const char *, // menuid const char *) // key
Check some file permissions related to the module. Do nothing most of the time.
PUBLIC VIRTUAL int LINUXCONF_MODULE::fixperm( bool, bool)
Give control to the module based on argv. A module foo may setup a symlink to linuxconf like this ln -s /bin/linuxconf /bin/foo and the execution of foo ..., will give control directly to the module. A module not supporting this, or which does not accept argv as an alias to itself will return LNCF_NOT_APPLICABLE. Any other value is the return code and the program (linuxconf) will terminate.
PUBLIC VIRTUAL int LINUXCONF_MODULE::execmain( int, // argc char *, // argv bool) // standalone
This function is called so a module can check is the current operation state of the service it manages matches the configuration state. It must compute the list of commands and actions required to bring the service up to date. Depending on the simul argument, it must do it or simply print it using the net_prtlog function. It returns 0 if all is ok, -1 if any error.
PUBLIC VIRTUAL int LINUXCONF_MODULE::probe( int, // Current level being probed // Only service of this level should do something. int, // target network runlevel of the probe // In which runlevel the machine is going to be // after the probe has completed bool) // simulation mode ?