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)
Sat, Apr 20, 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
Unknown Object (File)
Jul 2 2023, 11:08 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
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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