| commit | 29fa61fc5bc02f72f99e66ad50e4de8cb6b8490b | [log] [tgz] |
|---|---|---|
| author | David Wagner <david.wagner@intel.com> | Fri Dec 19 11:15:02 2014 +0100 |
| committer | David Wagner <david.wagner@intel.com> | Thu Jan 22 11:53:52 2015 +0100 |
| tree | 5786f9d76eae3a29eb7f22a0727921979e53c8bb | |
| parent | c39e7f4bbad04e92b53054b61b3f3deaa98ccd61 [diff] |
Extract and specialize domain import- and export-specific contexts Import and Export of ConfigurableDomains have different context needs: e.g. the value representation is only used for export; auto-validation is only meaningful for import whereas the "with settings" context is common to both. We create two new classes, derived from XmlDomainSerializingContext and move most of its content to each class it belongs to. Change-Id: I56589cdb3a8ea417e11d2ed98ccd055d7cdead67 Signed-off-by: David Wagner <david.wagner@intel.com>
- parameter/Android.mk[diff]
- parameter/CMakeLists.txt[diff]
- parameter/ConfigurableDomain.cpp[diff]
- parameter/ConfigurableDomain.h[diff]
- parameter/DomainConfiguration.cpp[diff]
- parameter/ParameterMgr.cpp[diff]
- parameter/SelectionCriterionRule.cpp[diff]
- parameter/XmlDomainExportContext.h[Added - diff]
- parameter/XmlDomainImportContext.h[Added - diff]
- parameter/XmlDomainSerializingContext.cpp[Deleted - diff]
- parameter/XmlDomainSerializingContext.h[diff]
- parameter/
- remote-process/
- remote-processor/
- Schemas/
- skeleton-subsystem/
- test/
- tools/
- utility/
- xmlserializer/
- .gitignore
- Android.mk
- CMakeLists.txt
- COPYING
- README.md
parameter-framework
Introduction
The parameter-framework is a plugin-based and rule-based framework for handling parameters. This means that you can:
- Describe your system's structure and its parameters (in XML) - aka. What;
- Write (in C++) or reuse a backend (aka. plugin) for accessing the parameters that you just described - aka. How;
- Define (in XML or in a domain-specific-language) conditions/rules upon which a given parameter must take a given value - aka. When.
Usage examples
Alsa controls on embedded platforms
The parameter-framework can be used to set the value of alsa controls (switches, volumes, etc.) on smartphones/tablets based on parameter-framework rules (in this example, they transcribe use-cases). For accessing parameters (i.e. alsa controls), you may use the alsa plugin.
Parameters in files
The filesystem plugin can be used to write parameters in files. This is particularly useful for files in /sys managing GPIOs.
More details
The parameter-framework's core comes in the form of a shared library. Its client has to provide:
- configuration files describing the structure of the system to be managed by the parameter-framework and what plugins it must use to read/write into each subsystem;
- a list of criteria (representing the state of the client) and their possible values;
- configuration files describing the value that each part of the system (aka parameter) must take - this is done by writing rules based on the criteria described above.
At runtime, the most usual communication between the client and the parameter-framework are:
- The update of criteria (that are used in the rules introduced above) and
- Update all relevant parameters according to the new criteria values. The parameter-framework uses the appropriate backend for writing the values in each underlying subsystem.
The parameter-framework comes with several tools, including a command-line interface: remote-process.
Going further
See the wiki on github.
Compiling
Run cmake . then make. You may then install libraries, headers and binaries with make install. By default, they are installed under /usr/local on unix OSes; if you want to install them under a custom directory, you may do so by passing it to the cmake . command; e.g.
cmake -DCMAKE_INSTALL_PREFIX=/path/to/custom/install .
Also, CMake can build a project out-of-tree, which is the recommended method:
mkdir /path/to/build/directory cd /path/to/build/directory cmake /path/to/parameter-framework/sources make