> On Feb 4, 2026, at 5:16 AM, Mark Johnston <[email protected]> wrote:
>
> On Mon, Dec 22, 2025 at 02:23:48AM +0000, Gleb Smirnoff wrote:
>> The branch main has been updated by glebius:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=349fcf079ca32d5c93e45366d2b27638747affeb
>>
>> commit 349fcf079ca32d5c93e45366d2b27638747affeb
>> Author: Gleb Smirnoff <[email protected]>
>> AuthorDate: 2025-12-21 21:31:43 +0000
>> Commit: Gleb Smirnoff <[email protected]>
>> CommitDate: 2025-12-22 02:23:14 +0000
>>
>> net: add ifnet_rename_event EVENTHANDLER(9) for interface renaming
>>
>> and don't trigger ifnet_arrival_event and ifnet_departure_event for a
>> rename, as the interface isn't being detached from any protocol. The
>> consumers of the arrival/departure events are divided into a few
>> categories:
>> - which indeed need to do the same actions as if interface was fully
>> detached and attached: routing socket and netlink notifications to
>> userland and the Linux sysfs. All addressed by this commit.
>> - which build their logic based on an interface name, but should actually
>> update their database on rename: packet filters. This commit leaves
>> them with the old behavior - emulate full detach & attach, but this
>> should be improved.
>> - which shouldn't do anything on rename, not touched by the commit.
>> - ng_ether and if_tuntap, that are special and will be addressed by
>> separate commits.
>
> Can we get rid of the IFF_RENAMING flag now? IIUC all of its uses are
> in ifnet_departure_event handlers to short-circuit the handler because
> the interface is not actually going away.
Now that we have ifnet_rename_event, I think the flag IFF_RENAMING is
not longer required.
Well there're still some consumers, they should be cleaned up prior to retire
IFF_RENAMING.
>
Best regards,
Zhenlei
