[OpenWrt-Devel] "UCI overlay" proposal

Matthias Schiffer mschiffer at universe-factory.net
Thu Mar 5 07:36:10 EST 2015

during the development of our Freifunk firmware framework "Gluon" we've
come to the conclusion that the current UCI configuration format using
static files doesn't always fit our needs. Therefore we propose a new
feature we've called "UCI overlays".

The basic idea is that we'd like to provide UCI configuration by other
means than the static files in /etc/config, for example from a database
or generated by scripts on the fly (the latter being our main usecase -
we'd like to generate configuration for netifd and fw3 based on
meta-configuration data). This should work transparently, without
needing changes in the config consumers (applications).

The overlay-provided configuration packages should be merged with the
config read from /etc/config. We'd like to generate both config sections
which may be overruled by corresponding options in /etc/config, and
read-only sections which can't be changed by the user through UCI.

We see two different ways to implement this:

(1) Make the "overlay" an alternative backend which uses the "file"
backend to merge generated config with the one from files

(2) Introduce overlays as a new concept in libuci

While the first option would need less changes in libuci, it doesn't
allow stacking different overlays, so we're in favour of option 2.

Both ways would need a config file (/etc/uci.conf?) to configure the
overlays being used. Our plan is to implement overlays as dlopen-able
plugins loaded from somewhere like /lib/uci/overlay so it is possible
for other packages to provide overlay implementations.

In addition, we'd like to add a new attribute "readonly" to the
uci_element structure so changing read-only configuration will fail as
soon as someone tries to uci_set it.

Does this sound reasonable? We can develop the needed extensions
ourselves, but of course we'd like to get this feature upstream to avoid
carrying the patches downstream indefinitly, so we're eager to know what
you think of this proposal.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150305/07afcd09/attachment.sig>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list