The UCI bridge will need to be implemented as an ABI-compatible extension or
replacement for libuci. It should allow to use ordinary UCI config files for
packages without ECE-UCI mappings; when an ECE-UCI mapping is defined, the
UCI config is replaced completely (the file in /etc/config might just contain
a comment referring to ECE). If an old config file is found for a package that
has a mapping defined, the old configuration will be imported as defined by the
If there are any UCI users which directly read the config files instead of using
libuci or the uci CLI tool, they must be converted to use uci to work with the
Types of mappings
For now, we define the following types of mappings:
Primitive ECE value <-> UCI option
Array of primitive ECE values <-> UCI list
Array items <-> unnamed UCI sections
Object properties <-> named UCI sections
Option and list mappings (1. and 2.) may either be given for a specific named
section, an indexed section (regardless of naming), or inside of section
mappings (3. and 4.).
Proposed mapping format
Like schemas, UCI mappings may be installed by any package. For now, we propose
to use one mapping file per UCI "package", so no merging of multiple mapping
files for a single configuration file is done.
There are two toplevel properties: static for mappings of indexed unnamed and
specific named sections (here an unnamed section of type system, and a section
of type timeserver with name ntp). The contained properties map options
and lists to ECE paths, specifying the types to use (mapping types 1 and 2).
The named section will create a named section of type led for each element
of the given path /system/leds (mapping type 4). The keys of the contained properties are relative
This example doesn't contain an unnamed section, which corresponds to mapping
This format is very simple and will need to be extended to support tree-like
mappings (i.e. UCI sections containing a "parent" element). Also, single UCI
options mapping to different ECE types aren't supported yet.