[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: support for dynamically loadable modules (ITS#196)



This is a multi-part message in MIME format.
--------------AE59CDE449605DBCA31A1DCE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've built a patch for loadable module support against OpenLDAP-devel of 19990608.
You can enable it by adding --enable-modules to the options for configure. To
compile you'll need GLib/GModule v1.2 (see  ftp://ftp.gtk.org/pub/gtk/v1.2/ ). The
patch can be found here:
 ftp://ftp.openldap.org/incoming/bb_dynmods_for_HEAD19990608.v0.1.gz

This patch is not complete: it will build a functional slapd server that can
dynamically load modules. However slapd will not contain any backends, expecting
them to be loaded dynamically. At the moment backend modules still have to be built
be hand. I do the following:
1) Run configure with every backend you want a module for enabled.
2) Make everything.
3) Go to the particular backend directories for example back-perl and do:
% gcc -g -O2 -shared -o libback-perl.so *.o
This works on my development platform (x86 linux with glibc2.0) at least. If you
use another compiler you may very well have to give it other options.
4) copy all modules to a suitable directory, say %installroot%/lib/modules
5) add loadmodule statements to your slapd.conf before any database configurations:

loadmodule /opt/openldap/lib/modules/libback-perl.so
etc.

The patch allows any shared object to be loaded, but only the slapd backends have
been modularized so far.

Brief description of implementation:

If the config parser finds a line starting with loadmodule it will call
load_module(const char* file_name, int argc, char *argv[]) in module.c. This
function will try to load the shared object / DLL in file 'file_name'. Then it
looks whether the loaded module contains the function init_module(int argc, char
*argv[]). If so, this function is called and the module does it's initialization
stuff like adding the backend it implements to the backend info list. If not, a
warning message is issued and slapd continues.
To facilitate modularizing of backends the function backend_add(BackendInfo
*aBackendInfo) has been added to backend.c. The changes to the backends are
minimal: just add an init_module function that call backend_add.

Issues & remarks:

As mentioned above the makefiles do not automatically build any modules. At the
moment I lack the knowledge  to add this in a portable way. Any help will be
appreciated much!

A choice has to be made about where modules will be located within the install dir
subtree. I propose lib/modules. Let me know if you think different. The
installation of modules is not in the makefile yet. Again, help will be
appreciated.

The current policy of --enable-modules is not to statically link in any backends.
Maybe it is useful to specify which backends should be linked statically even if
module support is enabled? Let me know if you think so, and how you think it should
be told to configure.

It's not illegal to load the same module twice or more! The module will be loaded
only once but the init_module function will be called each time (with the arguments
given in the slapd.conf).

Backend_add does not check whether the backend name you are trying to add already
is in the list. If so the new backend never will be used.

So fare I've tested the dynamic module support only on a Linux RedHat 5.2 x86
machine. I'd very much like to hear the results for other architectures.


If you have any remarks, questions or other feedback, please let me know!

Regards,

Bastiaan Bakker







--------------AE59CDE449605DBCA31A1DCE
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Bastiaan Bakker
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Bastiaan Bakker
n:              Bakker;Bastiaan
org:            LifeLine Networks BV
email;internet: Bastiaan.Bakker@lifeline.nl
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------AE59CDE449605DBCA31A1DCE--