Page MenuHomeFreeBSD

netinet: get interface event notifications directly via EVENTHANDLER(9)
ClosedPublic

Authored by glebius on Aug 10 2022, 4:12 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, May 23, 3:41 AM
Unknown Object (File)
Apr 20 2024, 12:52 PM
Unknown Object (File)
Jan 12 2024, 6:59 AM
Unknown Object (File)
Dec 20 2023, 4:48 AM
Unknown Object (File)
Sep 20 2023, 6:57 AM
Unknown Object (File)
Jul 2 2023, 11:22 AM
Unknown Object (File)
Jul 2 2023, 11:22 AM
Unknown Object (File)
Jul 2 2023, 11:21 AM
Subscribers

Details

Summary

The old mechanism of getting them via domains/protocols control input
is a relict from the previous century, when nothing like EVENTHANDLER(9)
existed yet. Retire PRC_IFDOWN/PRC_IFUP as netinet was the only one
to use them.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 46833
Build 43722: arc lint + arc unit

Event Timeline

bz added inline comments.
sys/sys/protosw.h
287

I'd leave the values as comments, e.g.:

/* 0 was PRC_IFDOWN */

if you really want to remove them. I assume it's unlikely to have out-of-tree code use them?

I can do it if you will. However, the longer plan is eliminate pr_ctlinput() with all these codes in favor of EVENTHANDLER for the internally generated messages. Then for ICMP messages remove the table that matches ICMP codes to PRC_ codes and use a straight demuxer of ICMP codes in a switch. So eventually all of PRC_ codes go away. And it is so pleasant to see zero results when you grep for PRC_FOO :)

I was just going by a few lines down where (like elsewhere) this was the best practice.

Sounds great! I wonder if that'll in the longer-term would make it easier to make the protocols loadable... something we pondered more than a decade ago ;-)

In D36116#819977, @bz wrote:

I was just going by a few lines down where (like elsewhere) this was the best practice.

Maybe I should just cleanse this cruft. Will never get resurrected for sure.

Sounds great! I wonder if that'll in the longer-term would make it easier to make the protocols loadable... something we pondered more than a decade ago ;-)

Definitely will make it easier! That's one of the goals.

This revision is now accepted and ready to land.Aug 11 2022, 3:38 PM