Chapter 8. Modules

Jelmer Vernooij

Samba Team

19 March 2003

Table of Contents

Advantages
Loading modules
Static modules
Shared modules
Writing modules
Static/Shared selection in configure.in

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(TALLOC_CTX *);

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(TALLOC_CTX *)
{
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;
}

The TALLOC_CTX pointer passed as a parameter must be a long-lived context, that will stay around for as long as the program that loads the module exists. It allows the caller to taloc_free any long lived data the module choses to place on this context on program exit (giving a cleaner valgrind trace). It should be used by modules in place of talloc_autofree_context(), use of which makes programs thread-unsafe. Modules that don't care about free on exist should use the NULL talloc context.

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 rebuilt in the 'modules_clean' make target. Practically, this means all c files that contain static_init_subsystem; calls need to be rebuilt.

Note

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.