The module commands now support an optional flag for arguments that when
enabled checks that the argument module name matches the registered domain
name. This can be used to enforce argument type validity for arguments
that are given to modules that expect objects of a certain type.
For example, this is used by the cache and dbfwfilter to prevent valid
filters but of the wrong type being given as arguments.
This directory is intended to be the default working directory for
relative pathname resolution. The actual implementation for
MXS_MODULE_PARAM_PATH is done at a later step.
This removes parts of the nearly identical code from all monitors.
The removal of monitor type specific event checking is done based on the
assumption that only the monitor that is monitoring the server can be the
cause for a state change. This removes the need to actually check that the
state change is relevant for each monitor and allows the event handling to
be moved into the core.
The configuration checks for module parameters are now fully in use. By
removing the hard-coded values from the list of accepted values, the
modules take control of what parameters are accepted.
The type represents byte sizes used for configuring buffers and file
sizes. The supported suffixes for binary units are k, m, g and t in both
upper and lower case.
To test the configuration validation and default value generation, the
functions needed to be refactored to allow parameters to be passed
directly to the function.
When a monitor is created at runtime, it also needs to have the default
parameters. Ideally, this would be done when the monitor is allocated but
because of the way the configuration is processed, we need to do it after
user defined parameters are added.
- All (but the printing/debug functions) are now in snake_case.
- Functions made const correct.
- All function prototypes now have named arguments.
Documentation still to be moved, and file possibly split into
include/mascale/server.h and server/core/maxscale/server.h
The setting up and the initialization of the query classifier has
now been separated. The gateway explicitly sets up the query
classifier (i.e. chooses which one to use and what arguments to
provide), but the actual initialization is performed as part of
the general module initialization.
The filters should use the same configuration parameters as other modules
use. This allows them to use the common configuration management functions
to get values from it.
If the enums are converted to the acutual enum values before they are
returned, this removes the need for the modules to process the enum
strings to enum values. This allows modules to use enumerations with
minimal effort.
The path type is validated if the module requested path
validation. Service checks can be done both on startup and at
runtime. This allows dynamic changes to module parameters to be validated
without a configuration context.
The options allow the modules to impose type specific restrictions on the
parameters. This can be used to offload file permission and mandatory
parameter checks to the core.
All monitors now declare the parameters that they use. This allows the
core to check the validity of the parameters before they are passed to the
monitor. It also simplifies the processing of the parameters as they are
guaranteed to be valid.
The declared parameters are now used to check whether the configuration is
valid. As the filters and monitors don't use the new declarations, the
code needs to be commented out. Once the parameter processing has been
migrated to the new system, the code can be enabled.
Filters, monitors and routers can now declare parameters and those
parameters will always be present. Currently, this removes the need to
parse simple values like booleans and integers.
Some of the more common parameter types could be added in the future
e.g. paths to files.
The MXS_MODULE structure now contains a member for parameters. This can be
used by the modules to declare accepted parameters, their types and the
default values. Currently only count, integer, boolean, string and enum
values are supported.
The MXS_MODULE structure of each module is now globally exposed by the
`get_module` function. This allows the module information of any module to
be queried.
This information can then be used to validate various things but the main
goal is to provide a way for modules to declare accepted parameters in the
MXS_MODULE structure. This will be done in a later commit.
Also the function documentation is now in the header file. This should
make it easier to read.
The MODULE_INFO is now the main object which is used by modules to convey
information to the MaxScale core. The MXS_MODULE name is more apt as it
now contains the actual module definition.
The old MODULES structure was moved into load_utils.c as an internal
implementation and was renamed so that it is not confused with the new
MODULE structure.
The modules are now declared with a common macro. This allows future
additions to the module loading process while also making the loaded
symbol name a constant.
This allows modules to only expose one entry point with a consistent
signature. In the future, this could be used to implement declarations of
module parameters.
- Rename session_getUser to session_get_user
- Change session_get_user and session_get_remote to take a const
SESSION* as argument and to return a const char*.
- Change server_get_persistent, so that user is passed as const.
- Update all users of these functions as appropriate.
The function is not capable of doing the right thing for an entire
account string, but only separately for user and host names, so the
function name should reflect that.
