Moved some typedefs to router.h and server.h, changed a few
constants to these enums. Renamed some types in config.h to
remove "Gateway".
There are still some functions in the public header which are
only used in core, but they seem to fit the theme of public functions
so were not moved.
The external config.h header defined functions and structures that are
intended to be used by modules. The internal header contains functions
that are used only by the MaxScale core.
The header is divided into two parts, an external and an internal one. The
actual splitting is done in a later commit and this commit only prepares
the header for the split.
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
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 configuration processing requires that all parameters for monitors
exist before they are used. This is wrong if we are aiming for a modular
system but is a necessary evil for the time being.
If no message is logged, it will be very hard to figure out where some
configurations are coming from. For this reason, it's good to log a
message whenever a persistent configuration change is taken into use.
The code prevented scaling by imposing global spinlocks for the DCBs and
SESSIONs. Removing this list means that a thread-local list must be taken
into use to replace it.
The service header in include/maxscale/ contains the public part of the
service API. These functions can be safely used by the modules.
The internal header located in service/core/maxscale/ is used by the core
to initialize MaxScale at startup or to provide other services in a more
controlled way (the config_runtime, for example).
The created listeners are now stored to disk like created servers
are. This allows them to be used even after a restart.
Currently, the listeners cannot be deleted and need to be manually
removed.
The modules can now return human-readable error messages to the caller of
the function. The internals of the modulecmd system also use this to
return errors to the users.
The error messages can be retrieved with a common error function which
should make it easy to use in various clients.
