Skip to end of metadata
Go to start of metadata

Introduction

Asterisk uses a standard config file format that is essentially:

[context]
variable=value

The file 'config.h' specifies a relatively simple API for parsing these config files. Configuration information can usually be reloaded by the Asterisk user via the Asterisk command-line or manager interfaces. These reloads run in a different thread than any created by the specific module being reloaded. It is very important to handle reloads in an atomic, thread-safe manner. To help ensure this, a new configuration API has been added on top of the config.h API: the Config Options API.

Components

user-defined config snapshot object - This is an astobj2 object containing pointers to any global options and ao2 containers for configurable items.

aco_info - Module-level config information.

aco_file - Information about a specific config file and how to process it.

aco_type - A mapping between categories in a config file and user-defined objects.

category - A section of a config field denoted by a bracketed name. A category named "general" might look like:

[general]
variable1 = value
variable2 = value2

aco_option - A configuration variable of a specific option type. An option may have a default value and has a handler responsible for parsing the textual representation of the option's value and storing its type-specific config object.

option handler - A callback function responsible for parsing the textual representation of an option's value and storing it in a config object.

default option handler - An option handler for non-custom options that is used by the Config Options API code.

custom option handler - A module-specific option handler for custom options.

Parsing overview

  1. Define an ao2_global_obj hold global the active config snapshot object.
  2. Define a structure to contain any global settings or containers used for configurable items as well as an ao2 allocator and destructor function for it.
  3. Define config types to map config categories to the appropriate internal types
  4. Create an aco_file for any config files that will be processed. Set the filename and aco_types that are valid for the file.
  5. Define module-level configuration parsing options in a config info struct
  6. Initialize the aco_info and register default and custom options with the config info struct
  7. Process the config via aco_process_config(), passing in whether or not this is a reload or not.

Using config data

A completely consistent snapshot of config data can be accessed via

Icon

It is important to note that upon reload, items are completely rebuilt. If a configured item (like a SIP peer) needs to maintain state information between reloads, it is important that it be stored in an object separate from the item in an ao2 object. The item can store a pointer to this state information. When allocating a new item that requires this state information, do a search for the item in the active config and store a reference to to its state in the newly allocated item. If no item is found, allocate a new state object and store that reference in the item. See skel_level_alloc and skel_find_or_create_state in apps/app_skel.c for an example.

  • No labels