Hi Hans I guess I should have double checked FS#713. I thought it was set to notify, and just wasn't touched. Sorry about that.
wrt: > As explained in FS#713 reverting this patch will lead to complaints > from people homenet is broken > (https://github.com/openwrt/openwrt/issues/346[1]); a more > fundamental fix is required possible in procd to fix the issue. Just a collection of thoughts: If HNET is "broken," then is HNET the daemon that needs a change not netifd? If a network parameter is a trivial change, then should a daemon use ubus/dbus/whatever to poll it on its own schedule? If a network parameter is critical to function like address (non-wildcard binding) or route, then isn't the network manager necessary to announce the surprise updates? If a package is "core," then shouldn't it be cared for more than something more external? Do we want dnsmasq to flush its cache frequently in the default LEDE distro, or do we want HNET to work (for how many users)? If procd isn't discerning about trigger types, then is netifd update premature? Should procd be fixed before netifd? As LEDE gets supplemented with more packages, we need delay-trigger control like LEDE, but frequent noise like this doesn't help? I see a few issues with a balanced path to a solution. So maybe a better plan could be revert this for _now_ and have a less troublesome change with procd and netifd updated coherently. Thanks Eric _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev