This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision |
| docs:techref:netifd [2021/01/05 15:35] – [Debugging] ssb | docs:techref:netifd [2023/10/06 04:17] (current) – update links vgaetera |
|---|
| * some scripts in ''/etc/hotplug.d''.) | * some scripts in ''/etc/hotplug.d''.) |
| |
| ''netifd'' is intended to stay compatible with the existing format of ''[[docs:guide-user:base-system:basic-networking|/etc/config/network]]'', the only exceptions being rare special cases like | ''netifd'' is intended to stay compatible with the existing format of ''[[docs:guide-user:network:network_configuration|/etc/config/network]]'', the only exceptions being rare special cases like |
| aliases or the overlay variables in ''/var/state'' (though even most of those can be easily emulated). | aliases or the overlay variables in ''/var/state'' (though even most of those can be easily emulated). |
| |
| |
| ==== Why do we want netifd? ==== | ==== Why do we want netifd? ==== |
| One thing that ''netifd'' does much better then old //OpenWrt-network configuration scripts// is handling configuration changes. With ''netfid'', when the file ''[[docs:guide-user:base-system:basic-networking|/etc/config/network]]'' changes, you no longer have to restart all interfaces. Simply run **''/etc/init.d/network reload''**. This will issue an ''ubus''-call to ''netifd'', telling it to figure out the difference between runtime state and the new config and apply only that. This works on a per-interface level, even with protocol handlers written as shell scripts. | One thing that ''netifd'' does much better then old //OpenWrt-network configuration scripts// is handling configuration changes. With ''netifd'', when the file ''[[docs:guide-user:network:network_configuration|/etc/config/network]]'' changes, you no longer have to restart all interfaces. Simply run **''/etc/init.d/network reload''**. This will issue an ''ubus''-call to ''netifd'', telling it to figure out the difference between runtime state and the new config and apply only that. This works on a per-interface level, even with protocol handlers written as shell scripts. |
| |
| It boils down to the fact that the current network and interface setup mechanisms (via network configuration scripts) are rather constrained and inflexible: | It boils down to the fact that the current network and interface setup mechanisms (via network configuration scripts) are rather constrained and inflexible: |