diff options
| author | Petr Štetiar <ynezz@true.cz> | 2023-03-09 09:30:19 +0100 |
|---|---|---|
| committer | Petr Štetiar <ynezz@true.cz> | 2023-03-29 09:54:51 +0200 |
| commit | 24e4ad798279345a462e97427bc94c7304f69c4b (patch) | |
| tree | 2ef380820a7d8659f0fd99e9ce335561d085c198 | |
| parent | f60e386b7ac48905ebe64a49684d983428b66a3c (diff) | |
| download | netifd-24e4ad798279345a462e97427bc94c7304f69c4b.tar.gz | |
bridge: make it more clear why the config was applied
In some cases we see, that the bridge configuration was applied, but its
not exactly clear why it was done, so lets add a simple debugging output
which should provide currently missing clue.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
| -rw-r--r-- | bridge.c | 14 |
1 files changed, 10 insertions, 4 deletions
@@ -1153,16 +1153,22 @@ bridge_reload(struct device *dev, struct blob_attr *attr) diff = 0; uci_blob_diff(tb_dev, otb_dev, &device_attr_list, &diff); - if (diff) - ret = DEV_CONFIG_RESTART; + if (diff) { + ret = DEV_CONFIG_RESTART; + D(DEVICE, "Bridge %s device attributes have changed, diff=0x%lx\n", + dev->ifname, diff); + } blobmsg_parse(bridge_attrs, __BRIDGE_ATTR_MAX, otb_br, blob_data(bst->config_data), blob_len(bst->config_data)); diff = 0; uci_blob_diff(tb_br, otb_br, &bridge_attr_list, &diff); - if (diff & ~(1 << BRIDGE_ATTR_PORTS)) - ret = DEV_CONFIG_RESTART; + if (diff & ~(1 << BRIDGE_ATTR_PORTS)) { + ret = DEV_CONFIG_RESTART; + D(DEVICE, "Bridge %s attributes have changed, diff=0x%lx\n", + dev->ifname, diff); + } bridge_config_init(dev); } |