Home | History | Annotate | Download | only in parameter-framework
      1 # parameter-framework
      2 
      3 [![Build Status](https://travis-ci.org/01org/parameter-framework.svg?branch=master)](https://travis-ci.org/01org/parameter-framework)
      4 [![Coverage Status](https://coveralls.io/repos/01org/parameter-framework/badge.svg?branch=master)](https://coveralls.io/r/01org/parameter-framework)
      5 
      6 ## Introduction
      7 
      8 The parameter-framework is a plugin-based and rule-based framework for handling
      9 parameters.  This means that you can:
     10 
     11 1. Describe your system's structure and its parameters (in XML) - aka. **What**;
     12 2. Write (in C++) or reuse a backend (aka. plugin) for accessing the parameters
     13 that you just described - aka. **How**;
     14 3. Define (in XML or in a domain-specific-language) conditions/rules upon which
     15 a given parameter must take a given value - aka. **When**.
     16 
     17 ![What, How, When](https://01org.github.io/parameter-framework/hosting/what-how-when.png)
     18 
     19 ### Usage examples
     20 
     21 #### Alsa controls on embedded platforms
     22 
     23 The parameter-framework can be used to set the value of alsa controls
     24 (switches, volumes, etc.) on smartphones/tablets based on parameter-framework
     25 rules (in this example, they transcribe use-cases).  For accessing parameters
     26 (i.e. alsa controls), you may use the
     27 [alsa plugin](https://github.com/01org/parameter-framework-plugins-alsa).
     28 
     29 #### Parameters in files
     30 
     31 The [filesystem plugin](https://github.com/01org/parameter-framework-plugins-filesystem)
     32 can be used to write parameters in files.  This is particularly useful for
     33 files in `/sys` managing GPIOs.
     34 
     35 ### More details
     36 
     37 The parameter-framework's core comes in the form of a shared library.  Its
     38 client has to provide:
     39 
     40 - configuration files describing the structure of the system to be managed by
     41   the parameter-framework and what plugins it must use to read/write into each
     42   subsystem;
     43 - a list of criteria (representing the state of the client) and their possible
     44   values;
     45 - configuration files describing the value that each part of the system (aka
     46   parameter) must take - this is done by writing rules based on the criteria
     47   described above.
     48 
     49 At runtime, the most usual communication between the client and the
     50 parameter-framework are:
     51 
     52 1. The update of *criteria* (that are used in the rules introduced above) and
     53 2. Update all relevant parameters according to the new criteria values.  The
     54    parameter-framework uses the appropriate backend for writing the values in
     55    each underlying subsystem.
     56 
     57 The parameter-framework comes with several tools, including a command-line
     58 interface: `remote-process`.
     59 
     60 ## Going further
     61 
     62 See [the wiki on github](https://github.com/01org/parameter-framework/wiki).
     63 
     64 ## Compiling
     65 
     66 Run `cmake .` then `make`.  You may then install libraries, headers and
     67 binaries with `make install`.  By default, they are installed under
     68 `/usr/local` on unix OSes; if you want to install them under a custom
     69 directory, you may do so by passing it to the `cmake .` command; e.g.
     70 
     71     cmake -DCMAKE_INSTALL_PREFIX=/path/to/custom/install .
     72 
     73 Also, CMake can build a project out-of-tree, which is the recommended method:
     74 
     75     mkdir /path/to/build/directory
     76     cd /path/to/build/directory
     77     cmake /path/to/parameter-framework/sources
     78     make
     79 
     80 After an install you may want to run the parameter-framework tests with
     81 `make test`.
     82