Adding upstream version 2:4.17.12+dfsg.upstream/2%4.17.12+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 921 insertions, 0 deletions

diff --git a/docs-xml/Samba-Developers-Guide/vfs.xml b/docs-xml/Samba-Developers-Guide/vfs.xml
new file mode 100644
index 0000000..268295a
--- /dev/null
+++ b/docs-xml/Samba-Developers-Guide/vfs.xml
@@ -0,0 +1,921 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<chapter id="vfs">
+<chapterinfo>
+	<author>
+		<firstname>Alexander</firstname><surname>Bokovoy</surname>
+		<affiliation>
+			<address><email>ab@samba.org</email></address>
+		</affiliation>
+	</author>
+	<author>
+		<firstname>Stefan</firstname><surname>Metzmacher</surname>
+		<affiliation>
+			<address><email>metze@samba.org</email></address>
+		</affiliation>
+	</author>
+	<pubdate> 27 May 2003 </pubdate>
+</chapterinfo>
+
+<title>VFS Modules</title>
+
+<sect1>
+<title>The Samba (Posix) VFS layer</title>
+
+<para>While most of Samba deployments are done using POSIX-compatible
+operating systems, there is clearly more to a file system than what is
+required by POSIX when it comes to adopting semantics of NT file
+system. Since Samba 2.2 all file-system related operations go through
+an abstraction layer for virtual file system (VFS) that is modelled
+after both POSIX and additional functions needed to transform NTFS
+semantics.
+</para>
+
+<para>
+This abstraction layer now provides more features than a regular POSIX
+file system could fill in. It is not required that all of them should
+be implemented by your particular file system.  However, when those
+features are available, Samba would advertize them to a CIFS client
+and they might be used by an application and in case of Windows client
+that might mean a client expects even more additional functionality
+when it encounters those features. There is a practical reason to
+allow handling of this snowfall without modifying the Samba core and
+it is fulfilled by providing an infrastructure to dynamically load VFS
+modules at run time.
+</para>
+
+<para>Each VFS module could implement a number of VFS operations. The
+way it does it is irrelevant, only two things actually matter: whether
+specific implementation wants to cooperate with other modules'
+implementations or not, and whether module needs to store additional
+information that is specific to a context it is operating in. Multiple
+VFS modules could be loaded at the same time and it is even possible
+to load several instances of the same VFS module with different
+parameters.
+</para>
+
+<sect2>
+<title>The general interface</title>
+
+<para>A VFS module has three major components:
+<itemizedlist>
+	<listitem><para><emphasis>An initialization function</emphasis> that is
+called during the module load to register implemented
+operations.</para></listitem>
+<listitem><para><emphasis>An operations table</emphasis> representing a
+mapping between statically defined module functions and VFS layer
+operations.</para></listitem>
+<listitem><para><emphasis>Module functions</emphasis> that do actual
+		work.</para></listitem>
+</itemizedlist>
+</para>
+
+<para>While this structure has been first applied to the VFS
+subsystem, it is now commonly used across all Samba 3 subsystems that
+support loadable modules. In fact, one module could provide a number
+of interfaces to different subsystems by exposing different
+<emphasis>operation tables</emphasis> through separate
+<emphasis>initialization functions</emphasis>.</para>
+
+<para><emphasis>An initialization function</emphasis> is used to
+register module with Samba run-time. As Samba internal structures and
+API are changed over lifetime, each released version has a VFS
+interface version that is increased as VFS development progresses or
+any of underlying Samba structures are changed in binary-incompatible
+way. When VFS module is compiled in, VFS interface version of that
+Samba environment is embedded into the module's binary object and is
+checked by the Samba core upon module load. If VFS interface number
+reported by the module isn't the same Samba core knows about, version
+conflict is detected and module dropped to avoid any potential memory
+corruption when accessing (changed) Samba structures.
+</para>
+
+<para>Therefore, initialization function passes three parameters to the
+VFS registration function, <literal>smb_register_vfs()</literal>
+<itemizedlist>
+	<listitem><para><emphasis>interface version number</emphasis>, as constant
+			<literal>SMB_VFS_INTERFACE_VERSION</literal>, </para></listitem>
+	<listitem><para><emphasis>module name</emphasis>, under which Samba core
+			will know it, and</para></listitem>
+	<listitem><para><emphasis>an operations' table</emphasis>.</para></listitem>
+</itemizedlist>
+</para>
+
+<para>The <emphasis>operations' table</emphasis> defines which
+functions in the module would correspond to specific VFS operations
+and how those functions would co-operate with the rest of VFS
+subsystem. Each operation could perform in a following ways:
+<itemizedlist>
+	<listitem><para><emphasis>transparent</emphasis>, meaning that while
+  operation is overridden, the module will still call a previous
+  implementation, before or after its own action. This mode is
+  indicated by the constant
+  <literal>SMB_VFS_LAYER_TRANSPARENT</literal>;</para>
+  </listitem>
+  <listitem><para><emphasis>opaque</emphasis>, for the implementations that
+  are terminating sequence of actions. For example, it is used to
+  implement POSIX operation on top of non-POSIX file system or even
+  not a file system at all, like a database for a personal audio
+  collection. Use constant <literal>SMB_VFS_LAYER_OPAQUE</literal> for
+  this mode;</para></listitem>
+  <listitem><para><emphasis>splitter</emphasis>, a way when some file system
+  activity is done in addition to the transparently calling previous
+  implementation. This usually involves mangling the result of that call
+  before returning it back to the caller. This mode is selected by
+  <literal>SMB_VFS_LAYER_SPLITTER</literal> constant;</para></listitem>
+  <listitem><para><emphasis>logger</emphasis> does not change anything or
+  performs any additional VFS operations. When
+  <emphasis>logger</emphasis> module acts, information about
+  operations is logged somewhere using an external facility (or
+  Samba's own debugging tools) but not the VFS layer. In order to
+  describe this type of activity use constant
+  <literal>SMB_VFS_LAYER_LOGGER</literal>;
+  </para>
+  </listitem>
+  <listitem><para>On contrary, <emphasis>scanner</emphasis> module does call
+  other VFS operations while processing the data that goes through the
+  system. This type of operation is indicated by the
+  <literal>SMB_VFS_LAYER_SCANNER</literal> constant.</para></listitem>
+</itemizedlist>
+</para>
+
+<para>Fundamentally, there are three types:
+<emphasis>transparent</emphasis>, <emphasis>opaque</emphasis>, and
+<emphasis>logger</emphasis>. <emphasis>Splitter</emphasis> and
+<emphasis>scanner</emphasis> may confuse developers (and indeed they
+are confused as our experience has shown) but this separation is to
+better expose the nature of a module's actions. Most of modules
+developed so far are either one of those three fundamental types with
+transparent and opaque being prevalent.
+</para>
+
+<para>
+Each VFS operation has a vfs_op_type, a function pointer and a handle
+pointer in the struct vfs_ops and tree macros to make it easier to
+call the operations.  (Take a look at
+<filename>include/vfs.h</filename> and
+<filename>include/vfs_macros.h</filename>.)
+</para>
+
+<para><programlisting>
+typedef enum _vfs_op_type {
+	SMB_VFS_OP_NOOP = -1,
+
+	...
+
+	/* File operations */
+
+	SMB_VFS_OP_OPEN,
+	SMB_VFS_OP_CLOSE,
+	SMB_VFS_OP_READ,
+	SMB_VFS_OP_WRITE,
+	SMB_VFS_OP_LSEEK,
+	SMB_VFS_OP_SENDFILE,
+
+	...
+
+	SMB_VFS_OP_LAST
+} vfs_op_type;
+</programlisting></para>
+
+<para>This struct contains the function and handle pointers for all operations.<programlisting>
+struct vfs_ops {
+	struct vfs_fn_pointers {
+		...
+
+		/* File operations */
+
+		int (*open)(struct vfs_handle_struct *handle,
+			struct connection_struct *conn,
+			const char *fname, int flags, mode_t mode);
+		int (*close)(struct vfs_handle_struct *handle,
+			struct files_struct *fsp, int fd);
+		ssize_t (*read)(struct vfs_handle_struct *handle,
+			struct files_struct *fsp, int fd, void *data, size_t n);
+		ssize_t (*write)(struct vfs_handle_struct *handle,
+			struct files_struct *fsp, int fd,
+			const void *data, size_t n);
+		SMB_OFF_T (*lseek)(struct vfs_handle_struct *handle,
+			struct files_struct *fsp, int fd,
+			SMB_OFF_T offset, int whence);
+		ssize_t (*sendfile)(struct vfs_handle_struct *handle,
+			int tofd, files_struct *fsp, int fromfd,
+			const DATA_BLOB *header, SMB_OFF_T offset, size_t count);
+
+		...
+	} ops;
+
+	struct vfs_handles_pointers {
+		...
+
+		/* File operations */
+
+		struct vfs_handle_struct *open;
+		struct vfs_handle_struct *close;
+		struct vfs_handle_struct *read;
+		struct vfs_handle_struct *write;
+		struct vfs_handle_struct *lseek;
+		struct vfs_handle_struct *sendfile;
+
+		...
+	} handles;
+};
+</programlisting></para>
+
+<para>
+This macros SHOULD be used to call any vfs operation.
+DO NOT ACCESS conn-&gt;vfs.ops.* directly !!!
+<programlisting>
+...
+
+/* File operations */
+#define SMB_VFS_OPEN(conn, fname, flags, mode) \
+	((conn)-&gt;vfs.ops.open((conn)-&gt;vfs.handles.open,\
+	 (conn), (fname), (flags), (mode)))
+#define SMB_VFS_CLOSE(fsp, fd) \
+	((fsp)-&gt;conn-&gt;vfs.ops.close(\
+	(fsp)-&gt;conn-&gt;vfs.handles.close, (fsp), (fd)))
+#define SMB_VFS_PREAD(fsp, fd, data, n, off) \
+	((fsp)-&gt;conn-&gt;vfs.ops.read(\
+	(fsp)-&gt;conn-&gt;vfs.handles.read,\
+	 (fsp), (fd), (data), (n), (off)))
+#define SMB_VFS_PWRITE(fsp, fd, data, n, off) \
+	((fsp)-&gt;conn-&gt;vfs.ops.write(\
+	(fsp)-&gt;conn-&gt;vfs.handles.write,\
+	 (fsp), (fd), (data), (n), (off)))
+#define SMB_VFS_LSEEK(fsp, fd, offset, whence) \
+	((fsp)-&gt;conn-&gt;vfs.ops.lseek(\
+	(fsp)-&gt;conn-&gt;vfs.handles.lseek,\
+	 (fsp), (fd), (offset), (whence)))
+#define SMB_VFS_SENDFILE(tofd, fsp, fromfd, header, offset, count) \
+	((fsp)-&gt;conn-&gt;vfs.ops.sendfile(\
+	(fsp)-&gt;conn-&gt;vfs.handles.sendfile,\
+	 (tofd), (fsp), (fromfd), (header), (offset), (count)))
+
+...
+</programlisting></para>
+
+</sect2>
+
+<sect2>
+<title>Possible VFS operation layers</title>
+
+<para>
+These values are used by the VFS subsystem when building the conn-&gt;vfs
+and conn-&gt;vfs_opaque structs for a connection with multiple VFS modules.
+Internally, Samba differentiates only opaque and transparent layers at this process.
+Other types are used for providing better diagnosing facilities.
+</para>
+
+<para>
+Most modules will provide transparent layers. Opaque layer is for modules
+which implement actual file system calls (like DB-based VFS). For example,
+default POSIX VFS which is built in into Samba is an opaque VFS module.
+</para>
+
+<para>
+Other layer types (logger, splitter, scanner) were designed to provide different
+degree of transparency and for diagnosing VFS module behaviour.
+</para>
+
+<para>
+Each module can implement several layers at the same time provided that only
+one layer is used per each operation.
+</para>
+
+<para><programlisting>
+typedef enum _vfs_op_layer {
+	SMB_VFS_LAYER_NOOP = -1,	/* - For using in VFS module to indicate end of array */
+					/*   of operations description */
+	SMB_VFS_LAYER_OPAQUE = 0,	/* - Final level, does not call anything beyond itself */
+	SMB_VFS_LAYER_TRANSPARENT,	/* - Normal operation, calls underlying layer after */
+					/*   possibly changing passed data */
+	SMB_VFS_LAYER_LOGGER,		/* - Logs data, calls underlying layer, logging may not */
+					/*   use Samba VFS */
+	SMB_VFS_LAYER_SPLITTER,		/* - Splits operation, calls underlying layer _and_ own facility, */
+					/*   then combines result */
+	SMB_VFS_LAYER_SCANNER		/* - Checks data and possibly initiates additional */
+					/*   file activity like logging to files _inside_ samba VFS */
+} vfs_op_layer;
+</programlisting></para>
+
+</sect2>
+
+</sect1>
+
+<sect1>
+<title>The Interaction between the Samba VFS subsystem and the modules</title>
+
+<sect2>
+<title>Initialization and registration</title>
+
+<para>
+As each Samba module a VFS module should have a
+<programlisting>NTSTATUS vfs_example_init(void);</programlisting> function if it's statically linked to samba or
+<programlisting>NTSTATUS init_module(void);</programlisting> function if it's a shared module.
+</para>
+
+<para>
+This should be the only non static function inside the module.
+Global variables should also be static!
+</para>
+
+<para>
+The module should register its functions via the
+<programlisting>
+NTSTATUS smb_register_vfs(int version, const char *name, vfs_op_tuple *vfs_op_tuples);
+</programlisting> function.
+</para>
+
+<variablelist>
+
+<varlistentry><term>version</term>
+<listitem><para>should be filled with SMB_VFS_INTERFACE_VERSION</para></listitem>
+</varlistentry>
+
+<varlistentry><term>name</term>
+<listitem><para>this is the name witch can be listed in the
+<command>vfs objects</command> parameter to use this module.</para></listitem>
+</varlistentry>
+
+<varlistentry><term>vfs_op_tuples</term>
+<listitem><para>
+this is an array of vfs_op_tuple's.
+(vfs_op_tuples is descripted in details below.)
+</para></listitem>
+</varlistentry>
+
+</variablelist>
+
+<para>
+For each operation the module wants to provide it has a entry in the
+vfs_op_tuple array.
+</para>
+
+<programlisting>
+typedef struct _vfs_op_tuple {
+	void* op;
+	vfs_op_type type;
+	vfs_op_layer layer;
+} vfs_op_tuple;
+</programlisting>
+
+<variablelist>
+
+<varlistentry><term>op</term>
+<listitem><para>the function pointer to the specified function.</para></listitem>
+</varlistentry>
+
+<varlistentry><term>type</term>
+<listitem><para>the vfs_op_type of the function to specified witch operation the function provides.</para></listitem>
+</varlistentry>
+
+<varlistentry><term>layer</term>
+<listitem><para>the vfs_op_layer in which the function operates.</para></listitem>
+</varlistentry>
+
+</variablelist>
+
+<para>A simple example:</para>
+
+<programlisting>
+static vfs_op_tuple example_op_tuples[] = {
+	{SMB_VFS_OP(example_connect),	SMB_VFS_OP_CONNECT,	SMB_VFS_LAYER_TRANSPARENT},
+	{SMB_VFS_OP(example_disconnect),	SMB_VFS_OP_DISCONNECT,	SMB_VFS_LAYER_TRANSPARENT},
+
+	{SMB_VFS_OP(example_rename),	SMB_VFS_OP_RENAME,	SMB_VFS_LAYER_OPAQUE},
+
+	/* This indicates the end of the array */
+	{SMB_VFS_OP(NULL),				SMB_VFS_OP_NOOP,	SMB_VFS_LAYER_NOOP}
+};
+
+NTSTATUS init_module(void)
+{
+	return smb_register_vfs(SMB_VFS_INTERFACE_VERSION, &quot;example&quot;, example_op_tuples);
+}
+</programlisting>
+
+</sect2>
+
+<sect2>
+<title>How the Modules handle per connection data</title>
+
+<para>Each VFS function has as first parameter a pointer to the modules vfs_handle_struct.
+</para>
+
+<programlisting>
+typedef struct vfs_handle_struct {
+	struct vfs_handle_struct  *next, *prev;
+	const char *param;
+	struct vfs_ops vfs_next;
+	struct connection_struct *conn;
+	void *data;
+	void (*free_data)(void **data);
+} vfs_handle_struct;
+</programlisting>
+
+<variablelist>
+
+<varlistentry><term>param</term>
+<listitem><para>this is the module parameter specified in the <command>vfs objects</command> parameter.</para>
+<para>e.g. for 'vfs objects = example:test' param would be &quot;test&quot;.</para></listitem>
+</varlistentry>
+
+<varlistentry><term>vfs_next</term>
+<listitem><para>This vfs_ops struct contains the information for calling the next module operations.
+Use the SMB_VFS_NEXT_* macros to call a next module operations and
+don't access handle-&gt;vfs_next.ops.* directly!</para></listitem>
+</varlistentry>
+
+<varlistentry><term>conn</term>
+<listitem><para>This is a pointer back to the connection_struct to witch the handle belongs.</para></listitem>
+</varlistentry>
+
+<varlistentry><term>data</term>
+<listitem><para>This is a pointer for holding module private data.
+You can alloc data with connection life time on the handle-&gt;conn-&gt;mem_ctx TALLOC_CTX.
+But you can also manage the memory allocation yourself.</para></listitem>
+</varlistentry>
+
+<varlistentry><term>free_data</term>
+<listitem><para>This is a function pointer to a function that free's the module private data.
+If you talloc your private data on the TALLOC_CTX handle-&gt;conn-&gt;mem_ctx,
+you can set this function pointer to NULL.</para></listitem>
+</varlistentry>
+
+</variablelist>
+
+<para>Some useful MACROS for handle private data.
+</para>
+
+<programlisting>
+#define SMB_VFS_HANDLE_GET_DATA(handle, datap, type, ret) { \
+	if (!(handle)||((datap=(type *)(handle)-&gt;data)==NULL)) { \
+		DEBUG(0,(&quot;%s() failed to get vfs_handle-&gt;data!\n&quot;,FUNCTION_MACRO)); \
+		ret; \
+	} \
+}
+
+#define SMB_VFS_HANDLE_SET_DATA(handle, datap, free_fn, type, ret) { \
+	if (!(handle)) { \
+		DEBUG(0,(&quot;%s() failed to set handle-&gt;data!\n&quot;,FUNCTION_MACRO)); \
+		ret; \
+	} else { \
+		if ((handle)-&gt;free_data) { \
+			(handle)-&gt;free_data(&amp;(handle)-&gt;data); \
+		} \
+		(handle)-&gt;data = (void *)datap; \
+		(handle)-&gt;free_data = free_fn; \
+	} \
+}
+
+#define SMB_VFS_HANDLE_FREE_DATA(handle) { \
+	if ((handle) &amp;&amp; (handle)-&gt;free_data) { \
+		(handle)-&gt;free_data(&amp;(handle)-&gt;data); \
+	} \
+}
+</programlisting>
+
+<para>How SMB_VFS_LAYER_TRANSPARENT functions can call the SMB_VFS_LAYER_OPAQUE functions.</para>
+
+<para>The easiest way to do this is to use the SMB_VFS_OPAQUE_* macros.
+</para>
+
+<programlisting>
+...
+/* File operations */
+#define SMB_VFS_OPAQUE_OPEN(conn, fname, flags, mode) \
+	((conn)-&gt;vfs_opaque.ops.open(\
+	(conn)-&gt;vfs_opaque.handles.open,\
+	 (conn), (fname), (flags), (mode)))
+#define SMB_VFS_OPAQUE_CLOSE(fsp, fd) \
+	((fsp)-&gt;conn-&gt;vfs_opaque.ops.close(\
+	(fsp)-&gt;conn-&gt;vfs_opaque.handles.close,\
+	 (fsp), (fd)))
+#define SMB_VFS_OPAQUE_READ(fsp, fd, data, n) \
+	((fsp)-&gt;conn-&gt;vfs_opaque.ops.read(\
+	(fsp)-&gt;conn-&gt;vfs_opaque.handles.read,\
+	 (fsp), (fd), (data), (n)))
+#define SMB_VFS_OPAQUE_WRITE(fsp, fd, data, n) \
+	((fsp)-&gt;conn-&gt;vfs_opaque.ops.write(\
+	(fsp)-&gt;conn-&gt;vfs_opaque.handles.write,\
+	 (fsp), (fd), (data), (n)))
+#define SMB_VFS_OPAQUE_LSEEK(fsp, fd, offset, whence) \
+	((fsp)-&gt;conn-&gt;vfs_opaque.ops.lseek(\
+	(fsp)-&gt;conn-&gt;vfs_opaque.handles.lseek,\
+	 (fsp), (fd), (offset), (whence)))
+#define SMB_VFS_OPAQUE_SENDFILE(tofd, fsp, fromfd, header, offset, count) \
+	((fsp)-&gt;conn-&gt;vfs_opaque.ops.sendfile(\
+	(fsp)-&gt;conn-&gt;vfs_opaque.handles.sendfile,\
+	 (tofd), (fsp), (fromfd), (header), (offset), (count)))
+...
+</programlisting>
+
+<para>How SMB_VFS_LAYER_TRANSPARENT functions can call the next modules functions.</para>
+
+<para>The easiest way to do this is to use the SMB_VFS_NEXT_* macros.
+</para>
+
+<programlisting>
+...
+/* File operations */
+#define SMB_VFS_NEXT_OPEN(handle, conn, fname, flags, mode) \
+	((handle)-&gt;vfs_next.ops.open(\
+	(handle)-&gt;vfs_next.handles.open,\
+	 (conn), (fname), (flags), (mode)))
+#define SMB_VFS_NEXT_CLOSE(handle, fsp, fd) \
+	((handle)-&gt;vfs_next.ops.close(\
+	(handle)-&gt;vfs_next.handles.close,\
+	 (fsp), (fd)))
+#define SMB_VFS_NEXT_READ(handle, fsp, fd, data, n) \
+	((handle)-&gt;vfs_next.ops.read(\
+	(handle)-&gt;vfs_next.handles.read,\
+	 (fsp), (fd), (data), (n)))
+#define SMB_VFS_NEXT_WRITE(handle, fsp, fd, data, n) \
+	((handle)-&gt;vfs_next.ops.write(\
+	(handle)-&gt;vfs_next.handles.write,\
+	 (fsp), (fd), (data), (n)))
+#define SMB_VFS_NEXT_LSEEK(handle, fsp, fd, offset, whence) \
+	((handle)-&gt;vfs_next.ops.lseek(\
+	(handle)-&gt;vfs_next.handles.lseek,\
+	 (fsp), (fd), (offset), (whence)))
+#define SMB_VFS_NEXT_SENDFILE(handle, tofd, fsp, fromfd, header, offset, count) \
+	((handle)-&gt;vfs_next.ops.sendfile(\
+	(handle)-&gt;vfs_next.handles.sendfile,\
+	 (tofd), (fsp), (fromfd), (header), (offset), (count)))
+...
+</programlisting>
+
+</sect2>
+
+</sect1>
+
+<sect1>
+<title>Upgrading to the New VFS Interface</title>
+
+<sect2>
+<title>Upgrading from 2.2.* and 3.0alpha modules</title>
+
+<orderedlist>
+<listitem><para>
+Add &quot;vfs_handle_struct *handle, &quot; as first parameter to all vfs operation functions.
+e.g. example_connect(connection_struct *conn, const char *service, const char *user);
+-&gt;   example_connect(vfs_handle_struct *handle, connection_struct *conn, const char *service, const char *user);
+</para></listitem>
+
+<listitem><para>
+Replace &quot;default_vfs_ops.&quot; with &quot;smb_vfs_next_&quot;.
+e.g. default_vfs_ops.connect(conn, service, user);
+-&gt;   smb_vfs_next_connect(conn, service, user);
+</para></listitem>
+
+<listitem><para>
+Uppercase all &quot;smb_vfs_next_*&quot; functions.
+e.g. smb_vfs_next_connect(conn, service, user);
+-&gt;   SMB_VFS_NEXT_CONNECT(conn, service, user);
+</para></listitem>
+
+<listitem><para>
+Add &quot;handle, &quot; as first parameter to all SMB_VFS_NEXT_*() calls.
+e.g. SMB_VFS_NEXT_CONNECT(conn, service, user);
+-&gt;   SMB_VFS_NEXT_CONNECT(handle, conn, service, user);
+</para></listitem>
+
+<listitem><para>
+(Only for 2.2.* modules)
+Convert the old struct vfs_ops example_ops to
+a vfs_op_tuple example_op_tuples[] array.
+e.g.
+<programlisting>
+struct vfs_ops example_ops = {
+	/* Disk operations */
+	example_connect,		/* connect */
+	example_disconnect,		/* disconnect */
+	NULL,				/* disk free *
+	/* Directory operations */
+	NULL,				/* opendir */
+	NULL,				/* readdir */
+	NULL,				/* mkdir */
+	NULL,				/* rmdir */
+	NULL,				/* closedir */
+	/* File operations */
+	NULL,				/* open */
+	NULL,				/* close */
+	NULL,				/* read  */
+	NULL,				/* write */
+	NULL,				/* lseek */
+	NULL,				/* sendfile */
+	NULL,				/* rename */
+	NULL,				/* fsync */
+	example_stat,			/* stat  */
+	example_fstat,			/* fstat */
+	example_lstat,			/* lstat */
+	NULL,				/* unlink */
+	NULL,				/* chmod */
+	NULL,				/* fchmod */
+	NULL,				/* chown */
+	NULL,				/* fchown */
+	NULL,				/* chdir */
+	NULL,				/* getwd */
+	NULL,				/* utime */
+	NULL,				/* ftruncate */
+	NULL,				/* lock */
+	NULL,				/* symlink */
+	NULL,				/* readlink */
+	NULL,				/* link */
+	NULL,				/* mknod */
+	NULL,				/* realpath */
+	NULL,				/* fget_nt_acl */
+	NULL,				/* get_nt_acl */
+	NULL,				/* fset_nt_acl */
+	NULL,				/* set_nt_acl */
+
+	NULL,				/* sys_acl_get_entry */
+	NULL,				/* sys_acl_get_tag_type */
+	NULL,				/* sys_acl_get_permset */
+	NULL,				/* sys_acl_get_qualifier */
+	NULL,				/* sys_acl_get_file */
+	NULL,				/* sys_acl_get_fd */
+	NULL,				/* sys_acl_clear_perms */
+	NULL,				/* sys_acl_add_perm */
+	NULL,				/* sys_acl_to_text */
+	NULL,				/* sys_acl_init */
+	NULL,				/* sys_acl_create_entry */
+	NULL,				/* sys_acl_set_tag_type */
+	NULL,				/* sys_acl_set_qualifier */
+	NULL,				/* sys_acl_set_permset */
+	NULL,				/* sys_acl_valid */
+	NULL,				/* sys_acl_set_file */
+	NULL,				/* sys_acl_set_fd */
+	NULL,				/* sys_acl_get_perm */
+	NULL,				/* sys_acl_free_text */
+	NULL,				/* sys_acl_free_acl */
+	NULL				/* sys_acl_free_qualifier */
+};
+</programlisting>
+-&gt;
+<programlisting>
+static vfs_op_tuple example_op_tuples[] = {
+	{SMB_VFS_OP(example_connect),	SMB_VFS_OP_CONNECT,	SMB_VFS_LAYER_TRANSPARENT},
+	{SMB_VFS_OP(example_disconnect),	SMB_VFS_OP_DISCONNECT,	SMB_VFS_LAYER_TRANSPARENT},
+
+	{SMB_VFS_OP(example_fstat), 	SMB_VFS_OP_FSTAT,	SMB_VFS_LAYER_TRANSPARENT},
+	{SMB_VFS_OP(example_stat),		SMB_VFS_OP_STAT,	SMB_VFS_LAYER_TRANSPARENT},
+	{SMB_VFS_OP(example_lstat), 	SMB_VFS_OP_LSTAT,	SMB_VFS_LAYER_TRANSPARENT},
+
+	{SMB_VFS_OP(NULL),				SMB_VFS_OP_NOOP,	SMB_VFS_LAYER_NOOP}
+};
+</programlisting>
+</para></listitem>
+
+<listitem><para>
+Move the example_op_tuples[] array to the end of the file.
+</para></listitem>
+
+<listitem><para>
+Add the init_module() function at the end of the file.
+e.g.
+<programlisting>
+NTSTATUS init_module(void)
+{
+	return smb_register_vfs(SMB_VFS_INTERFACE_VERSION,&quot;example&quot;,example_op_tuples);
+}
+</programlisting>
+</para></listitem>
+
+<listitem><para>
+Check if your vfs_init() function does more then just prepare the vfs_ops structs or
+remember the struct smb_vfs_handle_struct.
+<simplelist>
+<member>If NOT you can remove the vfs_init() function.</member>
+<member>If YES decide if you want to move the code to the example_connect() operation or to the init_module(). And then remove vfs_init().
+  e.g. a debug class registration should go into init_module() and the allocation of private data should go to example_connect().</member>
+</simplelist>
+</para></listitem>
+
+<listitem><para>
+(Only for 3.0alpha* modules)
+Check if your vfs_done() function contains needed code.
+<simplelist>
+<member>If NOT you can remove the vfs_done() function.</member>
+<member>If YES decide if you can move the code to the example_disconnect() operation. Otherwise register a SMB_EXIT_EVENT with smb_register_exit_event(); (Described in the <link linkend="modules">modules section</link>) And then remove vfs_done(). e.g. the freeing of private data should go to example_disconnect().
+</member>
+</simplelist>
+</para></listitem>
+
+<listitem><para>
+Check if you have any global variables left.
+Decide if it wouldn't be better to have this data on a connection basis.
+<simplelist>
+  <member>If NOT leave them as they are. (e.g. this could be the variable for the private debug class.)</member>
+  <member>If YES pack all this data into a struct. You can use handle-&gt;data to point to such a struct on a per connection basis.</member>
+</simplelist>
+
+  e.g. if you have such a struct:
+<programlisting>
+struct example_privates {
+	char *some_string;
+	int db_connection;
+};
+</programlisting>
+first way of doing it:
+<programlisting>
+static int example_connect(vfs_handle_struct *handle,
+	connection_struct *conn, const char *service,
+	const char* user)
+{
+	struct example_privates *data = NULL;
+
+	/* alloc our private data */
+	data = (struct example_privates *)talloc_zero(conn-&gt;mem_ctx, sizeof(struct example_privates));
+	if (!data) {
+		DEBUG(0,(&quot;talloc_zero() failed\n&quot;));
+		return -1;
+	}
+
+	/* init out private data */
+	data-&gt;some_string = talloc_strdup(conn-&gt;mem_ctx,&quot;test&quot;);
+	if (!data-&gt;some_string) {
+		DEBUG(0,(&quot;talloc_strdup() failed\n&quot;));
+		return -1;
+	}
+
+	data-&gt;db_connection = open_db_conn();
+
+	/* and now store the private data pointer in handle-&gt;data
+	 * we don't need to specify a free_function here because
+	 * we use the connection TALLOC context.
+	 * (return -1 if something failed.)
+	 */
+	VFS_HANDLE_SET_DATA(handle, data, NULL, struct example_privates, return -1);
+
+	return SMB_VFS_NEXT_CONNECT(handle,conn,service,user);
+}
+
+static int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd)
+{
+	struct example_privates *data = NULL;
+
+	/* get the pointer to our private data
+	 * return -1 if something failed
+	 */
+	SMB_VFS_HANDLE_GET_DATA(handle, data, struct example_privates, return -1);
+
+	/* do something here...*/
+	DEBUG(0,(&quot;some_string: %s\n&quot;,data-&gt;some_string));
+
+	return SMB_VFS_NEXT_CLOSE(handle, fsp, fd);
+}
+</programlisting>
+second way of doing it:
+<programlisting>
+static void free_example_privates(void **datap)
+{
+	struct example_privates *data = (struct example_privates *)*datap;
+
+	SAFE_FREE(data-&gt;some_string);
+	SAFE_FREE(data);
+
+	*datap = NULL;
+
+	return;
+}
+
+static int example_connect(vfs_handle_struct *handle,
+	connection_struct *conn, const char *service,
+	const char* user)
+{
+	struct example_privates *data = NULL;
+
+	/* alloc our private data */
+	data = (struct example_privates *)malloc(sizeof(struct example_privates));
+	if (!data) {
+		DEBUG(0,(&quot;malloc() failed\n&quot;));
+		return -1;
+	}
+
+	/* init out private data */
+	data-&gt;some_string = strdup(&quot;test&quot;);
+	if (!data-&gt;some_string) {
+		DEBUG(0,(&quot;strdup() failed\n&quot;));
+		return -1;
+	}
+
+	data-&gt;db_connection = open_db_conn();
+
+	/* and now store the private data pointer in handle-&gt;data
+	 * we need to specify a free_function because we used malloc() and strdup().
+	 * (return -1 if something failed.)
+	 */
+	SMB_VFS_HANDLE_SET_DATA(handle, data, free_example_privates, struct example_privates, return -1);
+
+	return SMB_VFS_NEXT_CONNECT(handle,conn,service,user);
+}
+
+static int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd)
+{
+	struct example_privates *data = NULL;
+
+	/* get the pointer to our private data
+	 * return -1 if something failed
+	 */
+	SMB_VFS_HANDLE_GET_DATA(handle, data, struct example_privates, return -1);
+
+	/* do something here...*/
+	DEBUG(0,(&quot;some_string: %s\n&quot;,data-&gt;some_string));
+
+	return SMB_VFS_NEXT_CLOSE(handle, fsp, fd);
+}
+</programlisting>
+</para></listitem>
+
+<listitem><para>
+To make it easy to build 3rd party modules it would be useful to provide
+configure.in, (configure), install.sh and Makefile.in with the module.
+(Take a look at the example in <filename>examples/VFS</filename>.)
+</para>
+
+<para>
+The configure script accepts <option>--with-samba-source</option> to specify
+the path to the samba source tree.
+It also accept <option>--enable-developer</option> which lets the compiler
+give you more warnings.
+</para>
+
+<para>
+The idea is that you can extend this
+<filename>configure.in</filename> and <filename>Makefile.in</filename> scripts
+for your module.
+</para></listitem>
+
+<listitem><para>
+Compiling &amp; Testing...
+<simplelist>
+<member><userinput>./configure <option>--enable-developer</option></userinput> ...</member>
+<member><userinput>make</userinput></member>
+<member>Try to fix all compiler warnings</member>
+<member><userinput>make</userinput></member>
+<member>Testing, Testing, Testing ...</member>
+</simplelist>
+</para></listitem>
+</orderedlist>
+</sect2>
+
+</sect1>
+
+<sect1>
+<title>Some Notes</title>
+
+<sect2>
+<title>Implement TRANSPARENT functions</title>
+
+<para>
+Avoid writing functions like this:
+
+<programlisting>
+static int example_close(vfs_handle_struct *handle, files_struct *fsp, int fd)
+{
+	return SMB_VFS_NEXT_CLOSE(handle, fsp, fd);
+}
+</programlisting>
+
+Overload only the functions you really need to!
+</para>
+
+</sect2>
+
+<sect2>
+<title>Implement OPAQUE functions</title>
+
+<para>
+If you want to just implement a better version of a
+default samba opaque function
+(e.g. like a disk_free() function for a special filesystem)
+it's ok to just overload that specific function.
+</para>
+
+<para>
+If you want to implement a database filesystem or
+something different from a posix filesystem.
+Make sure that you overload every vfs operation!!!
+</para>
+<para>
+Functions your FS does not support should be overloaded by something like this:
+e.g. for a readonly filesystem.
+</para>
+
+<programlisting>
+static int example_rename(vfs_handle_struct *handle, connection_struct *conn,
+			char *oldname, char *newname)
+{
+	DEBUG(10,(&quot;function rename() not allowed on vfs 'example'\n&quot;));
+	errno = ENOSYS;
+	return -1;
+}
+</programlisting>
+
+</sect2>
+
+</sect1>
+
+</chapter>