Add module command documetation

Added a document that describes the module command system and added the
necessary information in the dbfwfilter documentation.

The release notes also point to the newly created document.

Documentation/Documentation-Contents.md

@@ -32,6 +32,7 @@
  - [Routing Hints](Reference/Hint-Syntax.md)
  - [MaxBinlogCheck](Reference/MaxBinlogCheck.md)
  - [MaxScale REST API](REST-API/API.md)
+ - [Module Commands](Reference/Module-Commands.md)
 
 ## Tutorials
 

Documentation/Filters/Database-Firewall-Filter.md

@@ -161,12 +161,29 @@ The `users` directive defines the users to which the rule should be applied.
 
 The first keyword is `users`, which identifies this line as a user definition line.
 
-The second component is a list of user names and network addresses in the format *`user`*`@`*`0.0.0.0`*. The first part is the user name and the second part is the network address. You can use the `%` character as the wildcard to enable user name matching from any address or network matching for all users. After the list of users and networks the keyword match is expected. 
+The second component is a list of user names and network addresses in the format *`user`*`@`*`0.0.0.0`*. The first part is the user name and the second part is the network address. You can use the `%` character as the wildcard to enable user name matching from any address or network matching for all users. After the list of users and networks the keyword match is expected.
 
 After this either the keyword `any` `all` or `strict_all` is expected. This defined how the rules are matched. If `any` is used when the first rule is matched the query is considered blocked and the rest of the rules are skipped. If instead the `all` keyword is used all rules must match for the query to be blocked. The `strict_all` is the same as `all` but it checks the rules from left to right in the order they were listed. If one of these does not match, the rest of the rules are not checked. This could be useful in situations where you would for example combine `limit_queries` and `regex` rules. By using `strict_all` you can have the `regex` rule first and the `limit_queries` rule second. This way the rule only matches if the `regex` rule matches enough times for the `limit_queries` rule to match.
 
 After the matching part comes the rules keyword after which a list of rule names is expected. This allows reusing of the rules and enables varying levels of query restriction.
 
+## Module commands
+
+Read [Module Commands](../Reference/Module-Commands.md) documentation for details about module commands.
+
+The dbfwfilter supports the following module commands.
+
+### `dbfwfilter::rules/reload [FILE]`
+
+Load a new rule file or reload the current rules. New rules are only taken into
+use if they are successfully loaded and in cases where loading of the rules
+fail, the old rules remain in use. The _FILE_ argument is an optional path to a
+rule file and if it is not defined, the current rule file is used.
+
+### `dbfwfilter::rules`
+
+Shows the current statistics of the rules.
+
 ## Use Cases
 
 ### Use Case 1 - Prevent rapid execution of specific queries

Documentation/Reference/Module-Commands.md

@@ -0,0 +1,65 @@
+# Module commands
+
+Introduced in MaxScale 2.1, the module commands are special, module-specific
+commands. They allow the modules to expand beyond the capabilities of the
+module API. Currently, only MaxAdmin implements an interface to the module
+commands.
+
+All registered module commands can be shown with `maxadmin list functions` and
+they can be executed with `maxadmin call function <domain> <name> ARGS...` where
+_<domain>_ is the domain where the module registered the function and _<name>_
+is the name of the function. _ARGS_ is a function specific list of arguments.
+
+## Developer reference
+
+The module command API is defined in the _modulecmd.h_ header. It consists of
+various functions to register and call module commands. Read the function
+documentation in the header for more details.
+
+The following example registers the module command _my_command_ in the _my_module_ domain.
+
+```
+#include <maxscale/modulecmd.h>
+
+bool my_simple_cmd(const MODULECMD_ARG *argv)
+{
+    printf("%d arguments given\n", argv->argc);
+}
+
+int main(int argc, char **argv)
+{
+    modulecmd_arg_type_t my_args[] =
+    {
+        {MODULECMD_ARG_BOOLEAN, "This is a boolean parameter"},
+        {MODULECMD_ARG_STRING | MODULECMD_ARG_OPTIONAL, "This is an optional string parameter"}
+    };
+
+    // Register the command
+    modulecmd_register_command("my_module", "my_command", my_simple_cmd, 2, my_args);
+
+    // Find the registered command
+    const MODULECMD *cmd = modulecmd_find_command("my_module", "my_command");
+
+    // Parse the arguments for the command
+    const void *arglist[] = {"true", "optional string"};
+    MODULECMD_ARG *arg = modulecmd_arg_parse(cmd, arglist, 2);
+
+    // Call the module command
+    modulecmd_call_command(cmd, arg);
+
+    // Free the parsed arguments
+    modulecmd_arg_free(arg);
+    return 0;
+}
+```
+
+The array of _modulecmd_arg_type_t_ type is used to tell what kinds of arguments
+the command expects. The first argument is a SERVER which will be replaced with a
+pointer to a server. The second argument is an optional string argument.
+
+Arguments are passed to the parsing function as an array of void pointers. They
+are interpreted as the types the command expects.
+
+When the module command is executed, the _argv_ parameter for the
+_my_simple_cmd_ contains the parsed arguments received from the caller of the
+command.

Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md

@@ -104,6 +104,22 @@ following new commands were added to maxadmin, see output of `maxadmin help
 With these new features, you can start MaxScale without the servers and define
 them later.
 
+# Module commands
+
+## Module commands
+
+Introduced in MaxScale 2.1, the module commands are special, module-specific
+commands. They allow the modules to expand beyound the capabilities of the
+module API. Currently, only MaxAdmin implements an interface to the module
+commands.
+
+All registered module commands can be shown with `maxadmin list functions` and
+they can be executed with `maxadmin call function <domain> <name> ARGS...` where
+_<domain>_ is the domain where the module registered the function and _<name>_
+is the name of the function. _ARGS_ is a function specific list of arguments.
+
+Read [Module Commands](../Reference/Module-Commands.md) documentation for more details.
+
 ### Amazon RDS Aurora monitor
 
 The new [Aurora Monitor](../Monitors/Aurora-Monitor.md) module allows monitoring