Re: git: 349fcf079ca3 - main - net: add ifnet_rename_event EVENTHANDLER(9) for interface renaming
Date: Wed, 04 Feb 2026 22:40:07 UTC
On Wed, Feb 04, 2026 at 09:21:37AM +0800, Zhenlei Huang wrote: Z> >> commit 349fcf079ca32d5c93e45366d2b27638747affeb Z> >> Author: Gleb Smirnoff <glebius@FreeBSD.org> Z> >> AuthorDate: 2025-12-21 21:31:43 +0000 Z> >> Commit: Gleb Smirnoff <glebius@FreeBSD.org> Z> >> CommitDate: 2025-12-22 02:23:14 +0000 Z> >> Z> >> net: add ifnet_rename_event EVENTHANDLER(9) for interface renaming Z> >> Z> >> and don't trigger ifnet_arrival_event and ifnet_departure_event for a Z> >> rename, as the interface isn't being detached from any protocol. The Z> >> consumers of the arrival/departure events are divided into a few Z> >> categories: Z> >> - which indeed need to do the same actions as if interface was fully Z> >> detached and attached: routing socket and netlink notifications to Z> >> userland and the Linux sysfs. All addressed by this commit. Z> >> - which build their logic based on an interface name, but should actually Z> >> update their database on rename: packet filters. This commit leaves Z> >> them with the old behavior - emulate full detach & attach, but this Z> >> should be improved. Z> >> - which shouldn't do anything on rename, not touched by the commit. Z> >> - ng_ether and if_tuntap, that are special and will be addressed by Z> >> separate commits. Z> > Z> > Can we get rid of the IFF_RENAMING flag now? IIUC all of its uses are Z> > in ifnet_departure_event handlers to short-circuit the handler because Z> > the interface is not actually going away. Z> Z> Now that we have ifnet_rename_event, I think the flag IFF_RENAMING is Z> not longer required. Z> Z> Well there're still some consumers, they should be cleaned up prior to retire Z> IFF_RENAMING. 100% correct. Fell free to do that, or I can do that. -- Gleb Smirnoff