diff options
Diffstat (limited to 'docs/docbook/devdoc')
-rw-r--r-- | docs/docbook/devdoc/dev-doc.sgml | 6 | ||||
-rw-r--r-- | docs/docbook/devdoc/gencache.sgml | 119 | ||||
-rw-r--r-- | docs/docbook/devdoc/modules.sgml | 156 | ||||
-rw-r--r-- | docs/docbook/devdoc/packagers.sgml | 40 | ||||
-rw-r--r-- | docs/docbook/devdoc/rpc_plugin.sgml | 83 |
5 files changed, 0 insertions, 404 deletions
diff --git a/docs/docbook/devdoc/dev-doc.sgml b/docs/docbook/devdoc/dev-doc.sgml index 5e1af3d3a0..e256dbe3a2 100644 --- a/docs/docbook/devdoc/dev-doc.sgml +++ b/docs/docbook/devdoc/dev-doc.sgml @@ -12,9 +12,6 @@ <!ENTITY wins SYSTEM "wins.sgml"> <!ENTITY sam SYSTEM "sam.sgml"> <!ENTITY encryption SYSTEM "encryption.sgml"> -<!ENTITY rpc-plugin SYSTEM "rpc_plugin.sgml"> -<!ENTITY modules SYSTEM "modules.sgml"> -<!ENTITY packagers SYSTEM "packagers.sgml"> ]> <book id="Samba-Developers-Guide"> @@ -69,8 +66,5 @@ url="http://www.fsf.org/licenses/gpl.txt">http://www.fsf.org/licenses/gpl.txt</u &wins; &sam; &encryption; -&modules; -&rpc-plugin; -&packagers; </book> diff --git a/docs/docbook/devdoc/gencache.sgml b/docs/docbook/devdoc/gencache.sgml deleted file mode 100644 index 1ba2f77c9d..0000000000 --- a/docs/docbook/devdoc/gencache.sgml +++ /dev/null @@ -1,119 +0,0 @@ -<chapter id="gencache"> -<chapterinfo> - <author> - <firstname>Rafal</firstname><surname>Szczesniak</surname> - </author> - <pubdate>April 2003</pubdate> -</chapterinfo> - -<title>General cache mechanism and API</title> - -<sect1> -<title>Abstract</title> -<para> -General cache (gencache) was designed to combine various kinds of caching -mechanisms into one, defined by a simple API. This way, anyone can use it -to create their own caching layer on top of gencache. An example of -such approach is the netbios name cache. -</para> -</sect1> - -<sect1> -<title>The mechanism</title> -<para> -Gencache utilises <emphasise>tdb</emphasise> database, like many other -parts of Samba. As its origins are in Berkeley DB implementation, it -uses key/value pairs stored in binary file. The values gencache -operates on are string-based, however. This makes very easy to use it -in command line environment eg. to quickly take a look at what's in -the cache or set some value. -</para> - -<para> -All the data is stored in <filename>gencache.tdb</filename> -file. Records put there are in key/value format as mentioned below, -but as it's a cache, the timeout plays also important role and has a -special place in the key/value pair, as well as API. -</para> -</sect1> - - -<sect1> -<title>The data structure</title> -<para> -The record stored in <filename>gencache.tdb</filename> file consists -of the key, the value and the expiration timeout. While the first part -is stored completely independent from the others, the last two are -kept together. The form the record has is: -</para> - -<para><programlisting> -key: <string&bt; -value: <12-digit timeout&bt;/<string> -</programlisting></para> - -<para>The timeout part is the ASCII representation of -<emphasis>time_t</emphasis> value of the time when the cache entry -expires. Obviously the API, the programmer is provided with, hides this detail, -so that you don't have to care about checking it. Simply watch -carefully the return status of the function. -</para> -</sect1> - -<sect1> -<title>The API</title> - -<para><programlisting> -BOOL gencache_init() -</programlisting></para> - -<para>This is used to initialise to whole caching mechanism. It means -opening the file or creating it if non-existing. If it's already been -opened earlier, then the routine just does nothing and returns -<constant>true</constant>. If something goes wrong, say the user -doesn't have necessary rights, the function returns -<constant>false</constant>.</para> - -<para><programlisting> -BOOL gencache_shutdown() -</programlisting></para> - -<para>This is the proper way to close the cache file. It simply -returns <constant>true</constant> after successful closing file and -<constant>false</constant> upon a failure.</para> - -<para><programlisting> -BOOL gencache_set(const char* keystr, const char* value, time_t timeout) -</programlisting></para> - -<para>This is one of the most basic functions. What it allows you to -do is to set some particular cache entry. If the entry haven't -existed yet, the function will act just as it was "gencache_add" -function. If it's already been in the cache, the entry will be set to -the new value. In either case, the cache entry will be set with given -key, value and timeout. Thus it is comfortable way to just set the -entry and not care about the details.</para> - -<para><programlisting> -BOOL gencache_set_only(const char* keystr, const char* value, time_t timeout) -</programlisting></para> - -<para><programlisting> -BOOL gencache_del(const char* keystr) -</programlisting></para> - -<para><programlisting> -BOOL gencache_get(const char* keystr, char** valstr, time_t* timeout) -</programlisting></para> - -<para><programlisting> -void gencache_iterate(void (*fn)(const char* key, const char *value, time_t timeout, void* dptr), - void* data, const char* keystr_pattern) - -</programlisting></para> - -<sect1> -<title>Writing your own caching layer</title> -</sect1> - -</chapter> diff --git a/docs/docbook/devdoc/modules.sgml b/docs/docbook/devdoc/modules.sgml deleted file mode 100644 index 0bcdadc66c..0000000000 --- a/docs/docbook/devdoc/modules.sgml +++ /dev/null @@ -1,156 +0,0 @@ -<chapter id="modules"> -<chapterinfo> - <author> - <firstname>Jelmer</firstname><surname>Vernooij</surname> - <affiliation> - <orgname>Samba Team</orgname> - <address><email>jelmer@samba.org</email></address> - </affiliation> - </author> - <pubdate> 19 March 2003 </pubdate> -</chapterinfo> - -<title>Modules</title> - -<sect1> -<title>Advantages</title> - -<para> -The new modules system has the following advantages: -</para> - -<simplelist> -<member>Transparent loading of static and shared modules (no need -for a subsystem to know about modules)</member> -<member>Simple selection between shared and static modules at configure time</member> -<member>"preload modules" option for increasing performance for stable modules</member> -<member>No nasty #define stuff anymore</member> -<member>All backends are available as plugin now (including pdb_ldap and pdb_tdb)</member> -</simplelist> -</sect1> - -<sect1> -<title>Loading modules</title> - -<para> -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: -</para> - -<para><programlisting> -BOOL smb_register_passdb(const char *name, pdb_init_function init, int version); -</programlisting></para> - -<para> -This function will be called by the initialisation function of the module to -register itself. -</para> - -<sect2> -<title>Static modules</title> - -<para> -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 <filename>include/config.h</filename>): -</para> - -<para><programlisting> -/* Static init functions */ -#define static_init_pdb { pdb_mysql_init(); pdb_ldap_init(); pdb_smbpasswd_init(); pdb_tdbsam_init(); pdb_guest_init();} -</programlisting></para> - -<para> -These functions should be called before the subsystem is used. That -should be done when the subsystem is initialised or first used. -</para> - -</sect2> - -<sect2> -<title>Shared modules</title> - -<para> -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'. -</para> - -<para>After smb_probe_module() has been executed, the subsystem -should check again if the module has been registered. -</para> - -</sect2> -</sect1> - -<sect1> -<title>Writing modules</title> - -<para> -Each module has an initialisation function. For modules that are -included with samba this name is '<replaceable>subsystem</replaceable>_<replaceable>backend</replaceable>_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: -</para> - -<para><programlisting> -int init_module(void); -</programlisting></para> - -<para>This function should call one or more -registration functions. The function should return non-zero on success and zero on -failure.</para> - -<para>For example, pdb_ldap_init() contains: </para> - -<para><programlisting> -int pdb_ldap_init(void) -{ - smb_register_passdb("ldapsam", pdb_init_ldapsam, PASSDB_INTERFACE_VERSION); - smb_register_passdb("ldapsam_nua", pdb_init_ldapsam_nua, PASSDB_INTERFACE_VERSION); - return TRUE; -} -</programlisting></para> - -<sect2> -<title>Static/Shared selection in configure.in</title> - -<para> -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. -</para> - -<para> -On the bottom of configure.in, SMB_MODULE() should be called -for each module and SMB_SUBSYSTEM() for each subsystem. -</para> - -<para>Syntax:</para> - -<para><programlisting> -SMB_MODULE(<replaceable>subsystem</replaceable>_<replaceable>backend</replaceable>, <replaceable>object files</replaceable>, <replaceable>plugin name</replaceable>, <replaceable>subsystem name</replaceable>, <replaceable>static_action</replaceable>, <replaceable>shared_action</replaceable>) -SMB_SUBSYSTEM(<replaceable>subsystem</replaceable>) -</programlisting></para> - -<para>Also, make sure to add the correct directives to -<filename>Makefile.in</filename>. <replaceable>@SUBSYSTEM_STATIC@</replaceable> -will be replaced with a list of objects files of the modules that need to -be linked in statically. <replaceable>@SUBSYSTEM_MODULES@</replaceable> will -be replaced with the names of the plugins to build. -</para> - -<para>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 <command>static_init_subsystem;</command> calls need to be rebuilded. -</para> - -</sect2> -</sect1> -</chapter> diff --git a/docs/docbook/devdoc/packagers.sgml b/docs/docbook/devdoc/packagers.sgml deleted file mode 100644 index fb47c7305c..0000000000 --- a/docs/docbook/devdoc/packagers.sgml +++ /dev/null @@ -1,40 +0,0 @@ -<chapter id="Packaging"> -<chapterinfo> - <author> - <firstname>Jelmer</firstname><surname>Vernooij</surname> - </author> -</chapterinfo> - -<title>Notes to packagers</title> - -<sect1> -<title>Versioning</title> - -<para>Please, please update the version number in -<filename>source/include/version.h</filename> to include the versioning of your package. This makes it easier to distinguish standard samba builds -from custom-build samba builds (distributions often patch packages). For -example, a good version would be: </para> - -<para><programlisting> -Version 2.999+3.0.alpha21-5 for Debian -</programlisting></para> - -</sect1> - -<sect1> -<title>Modules</title> - -<para>Samba now has support for building parts of samba as plugins. This -makes it possible to, for example, put ldap or mysql support in a seperate -package, thus making it possible to have a normal samba package not -depending on ldap or mysql. To build as much parts of samba -as a plugin, run: </para> - -<para><programlisting> -./configure --with-shared-modules=rpc,vfs,auth,pdb,charset -</programlisting></para> - -</sect1> - - -</chapter> diff --git a/docs/docbook/devdoc/rpc_plugin.sgml b/docs/docbook/devdoc/rpc_plugin.sgml deleted file mode 100644 index c83742a247..0000000000 --- a/docs/docbook/devdoc/rpc_plugin.sgml +++ /dev/null @@ -1,83 +0,0 @@ -<chapter id="rpc-plugin"> -<chapterinfo> - <author> - <firstname>Anthony</firstname><surname>Liguori</surname> - <affiliation> - <orgname>IBM</orgname> - <address><email>aliguor@us.ibm.com</email></address> - </affiliation> - </author> - <author> - <firstname>Jelmer</firstname><surname>Vernooij</surname> - <affiliation> - <orgname>Samba Team</orgname> - <address><email>jelmer@samba.org</email></address> - </affiliation> - </author> - <pubdate>January 2003</pubdate> -</chapterinfo> - -<title>RPC Pluggable Modules</title> - -<sect1> -<title>About</title> - -<para> -This document describes how to make use the new RPC Pluggable Modules features -of Samba 3.0. This architecture was added to increase the maintainability of -Samba allowing RPC Pipes to be worked on separately from the main CVS branch. -The RPM architecture will also allow third-party vendors to add functionality -to Samba through plug-ins. -</para> - -</sect1> - -<sect1> -<title>General Overview</title> - -<para> -When an RPC call is sent to smbd, smbd tries to load a shared library by the -name <filename>librpc_<pipename>.so</filename> to handle the call if -it doesn't know how to handle the call internally. For instance, LSA calls -are handled by <filename>librpc_lsass.so</filename>.. -These shared libraries should be located in the <filename><sambaroot>/lib/rpc</filename>. smbd then attempts to call the init_module function within -the shared library. Check the chapter on modules for more information. -</para> - -<para> -In the init_module function, the library should call -rpc_pipe_register_commands(). This function takes the following arguments: -</para> - -<para><programlisting> -int rpc_pipe_register_commands(const char *clnt, const char *srv, - const struct api_struct *cmds, int size); -</programlisting></para> - -<variablelist> - -<varlistentry><term>clnt</term> -<listitem><para>the Client name of the named pipe</para></listitem> -</varlistentry> - -<varlistentry><term>srv</term> -<listitem><para>the Server name of the named pipe</para></listitem> -</varlistentry> - -<varlistentry><term>cmds</term> -<listitem><para>a list of api_structs that map RPC ordinal numbers to function calls</para></listitem> -</varlistentry> - -<varlistentry><term>size</term> -<listitem><para>the number of api_structs contained in cmds</para></listitem> -</varlistentry> - -</variablelist> - -<para> -See rpc_server/srv_reg.c and rpc_server/srv_reg_nt.c for a small example of -how to use this library. -</para> - -</sect1> -</chapter> |