[OpenWrt-Devel] UCI config bug or intent?

Yousong Zhou yszhou4tech at gmail.com
Fri Apr 3 10:44:25 EDT 2015


On Apr 3, 2015 2:27 PM, "Dominik Taborsky" <dominik.taborsky at nic.cz> wrote:
>
> Any thoughts on this?
>
> If anything, could anyone point me the right direction so I can fix it
myself?
>
>
>
> On 03/25/2015 11:28 AM, Dominik Taborsky wrote:
>>
>> Hello,
>>
>> a colleague of mine discovered a problem when using UCI: when there's a
clash of identifiers, they mix together regardless of their type and the
last type is set as the type of the identifier. Let me show an example:
>>
>> root at turris:/etc/config# cat conflicting_config
>> config typeA 'sec1'
>>         list device 'dev1'
>>         list ignore 'dev2'
>>
>> config typeA 'sec2'
>>         list device 'dev2'
>>         list ignore 'dev3'
>>
>> config typeB 'sec1'
>>         list activate 'dev3'
>>         list activate 'dev4'
>>         option socket 'false'
>>

Section names are supposed to be unique within a uci package unit since we
allow actions such as "uci set pkgname.secname.optname=xxx".

>> root at turris:/etc/config# uci show conflicting_config
>> conflicting_config.sec1=typeB
>> conflicting_config.sec1.device=dev1
>> conflicting_config.sec1.ignore=dev2
>> conflicting_config.sec1.activate=dev3 dev4
>> conflicting_config.sec1.socket=false
>> conflicting_config.sec2=typeA
>> conflicting_config.sec2.device=dev2
>> conflicting_config.sec2.ignore=dev3
>>
>>
>> root at turris:/etc/config# uci show conflicting_config. at typeA[0]
>> conflicting_config.sec2=typeA
>> conflicting_config.sec2.device=dev2
>> conflicting_config.sec2.ignore=dev3
>>
>>
>> As you can see, UCI shows only one section named 'sec1' of typeB, while
there are two sections of that name of different types. It mixes the
options and lists together and does not report any problem with this. I
would expect either to report a problem or consider these as different
objects with the same name. A workaround for this is to use anonymous
sections with an option with the name as the value, but I still think there
at least should be a warning. I don't know how to report such a problem
from within the UCI library though.
>>

How about warning on command line in normal mode and error when parsing in
strict mode?

cheers,
                yousong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150403/b3e730f0/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list