JelmerVernooij
Samba Team
jelmer@samba.org
StefanMetzmacher
metze@metzemix.de
events interface
17 September 2003
Modules
Advantages
The new modules system has the following advantages:
Transparent loading of static and shared modules (no need
for a subsystem to know about modules)
Simple selection between shared and static modules at configure time
"preload modules" option for increasing performance for stable modules
No nasty #define stuff anymore
All backends are available as plugin now (including pdb_ldap and pdb_tdb)
Loading modules
Some subsystems in samba use different backends. These backends can be
either statically linked in to samba or available as a plugin. A subsystem
should have a function that allows a module to register itself. For example,
the passdb subsystem has:
NTSTATUS smb_register_passdb(int version, const char *name, pdb_init_function init);
This function will be called by the initialisation function of the module to
register itself.
Static modules
The modules system compiles a list of initialisation functions for the
static modules of each subsystem. This is a define. For example,
it is here currently (from include/config.h):
/* Static init functions */
#define static_init_pdb { pdb_mysql_init(); pdb_ldap_init(); pdb_smbpasswd_init(); pdb_tdbsam_init(); pdb_guest_init();}
These functions should be called before the subsystem is used. That
should be done when the subsystem is initialised or first used.
Shared modules
If a subsystem needs a certain backend, it should check if it has
already been registered. If the backend hasn't been registered already,
the subsystem should call smb_probe_module(char *subsystem, char *backend).
This function tries to load the correct module from a certain path
($LIBDIR/subsystem/backend.so). If the first character in 'backend'
is a slash, smb_probe_module() tries to load the module from the
absolute path specified in 'backend'.
After smb_probe_module() has been executed, the subsystem
should check again if the module has been registered.
Writing modules
Each module has an initialisation function. For modules that are
included with samba this name is 'subsystem_backend_init'. For external modules (that will never be built-in, but only available as a module) this name is always 'init_module'. (In the case of modules included with samba, the configure system will add a #define subsystem_backend_init() init_module()).
The prototype for these functions is:
NTSTATUS init_module(void);
This function should call one or more
registration functions. The function should return NT_STATUS_OK on success and
NT_STATUS_UNSUCCESSFUL or a more useful nt error code on failure.
For example, pdb_ldap_init() contains:
NTSTATUS pdb_ldap_init(void)
{
smb_register_passdb(PASSDB_INTERFACE_VERSION, "ldapsam", pdb_init_ldapsam);
smb_register_passdb(PASSDB_INTERFACE_VERSION, "ldapsam_nua", pdb_init_ldapsam_nua);
return NT_STATUS_OK;
}
Static/Shared selection in configure.in
Some macros in configure.in generate the various defines and substs that
are necessary for the system to work correct. All modules that should
be built by default have to be added to the variable 'default_modules'.
For example, if ldap is found, pdb_ldap is added to this variable.
On the bottom of configure.in, SMB_MODULE() should be called
for each module and SMB_SUBSYSTEM() for each subsystem.
Syntax:
SMB_MODULE(subsystem_backend, object files, plugin name, subsystem name, static_action, shared_action)
SMB_SUBSYSTEM(subsystem,depfile)
The depfile for a certain subsystem is the file that calls the
initialisation functions for the statically built in modules.
@SUBSYSTEM_MODULES@ in Makefile.in will
be replaced with the names of the plugins to build.
You must make sure all .c files that contain defines that can
be changed by ./configure are rebuilded in the 'modules_clean' make target.
Practically, this means all c files that contain static_init_subsystem; calls need to be rebuilded.
There currently also is a configure.in command called SMB_MODULE_PROVIVES().
This is used for modules that register multiple things. It should not
be used as probing will most likely disappear in the future.
Registration of events
Intention
For some modules it is necessary to drop idle database connections,
or do other things periodically.
Some modules need to do close database connections or similar things
when the server exits.
Advantages
The event registration system has the following advantages:
Every module is able to register/unregister idle or exit handlers called from the main server loop
No need for hacking the main server anymore
General stuff
Each event has an event_id of type smb_event_id_t, which identifies the event in its event list.
(Take a look at include/module.h and lib/module.c.)
There are currently two event types:
idle events
exit events
Type: idle event
Idle events are called periodically from the main server loop.
if the specified interval is less or equal than 0, the default SMB_IDLE_EVENT_DEFAULT_INTERVAL (180 s) is used.
if the specified interval is less than SMB_IDLE_EVENT_MIN_INTERVAL (30 s), SMB_IDLE_EVENT_MIN_INTERVAL is used.
In any other case the specified interval is used.
the real interval can be differ from the specified interval about up to +/- 30 s.
Idle events can be registered via the
smb_event_id_t smb_register_idle_event(smb_idle_event_fn *fn, void *data, time_t interval);
function.
fn
the function pointer to idle handler function.
this function must have the following prototype!
void example_idle_event_fn(void **data, time_t *interval, time_t now);
data
this is a pointer to private data which is passed to the idle function when it's called.
interval
this is a pointer to the time_t interval in witch the idle handler function is called.
the idle handler is able to change it's interval.
the event_id is returned on succes, on failure SMB_EVENT_ID_INVALID is returned.
Idle events can be unregistered via the
BOOL smb_unregister_idle_event(smb_event_id_t id);
function.
True is returned on success, False on failure.
Type: exit event
Exit events are called when the server exits
Exit events can be registered via the
smb_event_id_t smb_register_exit_event(smb_exit_event_fn *fn, void *data);
function.
fn
the function pointer to exit handler function.
this function must have the following prototype!
void example_exit_event_fn(void **data);
data
this is a pointer to private data which is passed to the exit function when it's called.
the event_id is returned on success, on failure SMB_EVENT_ID_INVALID is returned.
Exit events can be unregistered via the
BOOL smb_unregister_exit_event(smb_event_id_t id);
function.
True is returned on succes, False on failure.