Hi, 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. Regards, Matthias
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
