4 Features

Features provided by the festplugin system are very minmal to allow the maximum of flexibility. In a certain sens it only exports the suitable dlopen methods of the c library to the scheme interface. Anyway there should be a way to keep track of the handle to allow plugin to be closed. The rest of the tasks is dedicated to the plugin developers. Therefore only an open (4.1) and a close (4.2) method are provided. The first one can surely not be called from the plugin itself as anyone can understand. For the second one it might look more subtle but if a plugin try to close itself it will lead to a segfault. Hence it seems to be clear at this point that when the plugin should be closed from the scheme level, the scheme level should provide the “handle” of the given plugin. In the actual implementation, this handle can be kept in a class that provides a suitable handle() method. An object of this class type will be returned by the open method and passed as an argument to the close method. Such an object should in fact inherit from the FP_MANAGER class defined in festplugin.H.

More precisely :

4.1 festplugin_open

The festplugin system exports the festplugin_open method to the scheme interface.

4.1.1 Parameters

The festplugin_open method takes three parameters :

4.1.1.1 PATH

Is the full path to the plugin e.g. “/usr/lib/franfest/franfest.so”

4.1.1.2 INIT

The name of the initial method that should be provided by the plugin implementation (see 5.1.1.)

4.1.1.3 MODE

The mode in which plugin will be opened.

4.1.2 Return value

The festplugin_open method returns a LISP object. This object is NIL if something goes wrong in the open process and the object returned by the initial method otherwise (see 5.1.1.) Hence developer of the plugin may decide which type of LISP object will control the plugin and from now, plugin may be fullly controlled from scheme level.

4.2 festplugin_close

4.2.1 Parameters

A lisp object from which the plugin handle can be retrieved. Then the dlclose routine is applied on the handle.

Notice that c object will be deleted by the close method. So any task that should be performed at closing time might be implemented in the object destructor.

4.3 festpluging_track

The difference with the previous function ‘festplugin_open’ (cf. 4.1 ,) is that this one passes ‘path’ and ‘mode’ to the init function of the dynamically loaded module. This init function should hence be of type ‘festplugin_track_function’ instead of ‘festplugin_init_function’. This second scheme is more suitable if plugin manager is implemented as ‘FP_TRACKER’ instead of ‘FP_MANAGER’.