Hi Felix,

An aliased interface can be specified as bridge member which is
usefull in case the underlying device is dynamically created.
In case the device is not yet present an empty string will be
displayed in the ubus bridge member section as the aliased device
ifname has not yet been set; not displaying an empty string can easily
be fixed in bridge_dump_info.
But the device ifname is also copied to the bridge member name in
bridge_create_member which is used as key when adding the bridge
member to the vlist members list.
Here it gets a bit ugly when the aliased device name is updated as the
bridge member name does not line up anymore with the device name
(funny enough doing a network reload will create a new bridge member
based on the new device name and will delete the old one).
The device event DEV_EVENT_UPDATE_IFNAME could be used in the
bridge_member_cb function to change the bridge member name but I'm not
sure what the best approach would be in that case.
Should we just create a new bridge member via bridge_create_member
based on the new device name and delete the old bridge member ? This
has as drawback that a topology
 DEV_EVENT_TOPO_CHANGE will be triggered (which is in fact not the
case ...) and the bridge member will be removed/added from the bridge
in the kernel.
Another option would be to update the bridge member name but since
this is used as the key in the vlist it requires the element to be
removed and added again in the vlist; but vlist has no such api and
using directly the avl primitives seems a bit hacky ...
Any opinion on the above mentioned proposals or other suggestions ?


Lede-dev mailing list

Reply via email to